At our sister site Stack Overflow a question can be on-topic even when its only tag(s) is/are for the Python programming language and a complex system of python-* tagging has evolved there to meet those requirements.

How should we tag questions that use the Python programming language with spatial libraries here at GIS SE?

The python-* tags which GIS SE currently has available to do this are:


3 Answers 3


My preference would be to standardize on StackOverflow's Python tag names (python, python-2.x, python-3.x, python-2.6, python-2.7, python-3.4, etc) as well as their tagging recommendations according to the Python tag wiki @ChrisW mentioned:

Use the tag for all Python related questions. If you believe your question includes issues specific to incompatibilities between Python 2.x and Python 3.x, use or in addition to the main tag. If you believe your question may be even more specific, you can include a version specific tag such as .

I don't think we should require, or even strongly encourage, including the Python version family tags (python-2.x and python-3.x) on every Python question, because in many (most?) cases it will be inferable from the context and other tags of the question (using ArcGIS Pro vs. ArcGIS 10.x, for example).

However, if an asker believes that a problem is specific to a family- or dot-release version of Python then they should be able to use the more specific tag. I think that in such cases they should also include the generic python tag, as many more people will be following the python tag than the more specific tags.


You've mentioned it already, but the first thing that popped into my mind when I read this was QGIS. The problem here is that version numbers mean different things depending on the software. You can't really say Arc 9.x, and depending on what you're asking about you can't say 10.x either. I don't know enough about how QGIS works - if it's similar or if you could do 1.x, 2.x etc. (my guess is not).

Because I am also not familiar with Python to that extent, I cannot offer an informed opinion whether coarser or more fine grained version tags should be used for Python. If an obvious, logical numbering break isn't used by the software (ie, 2.x and 3.x) to determine what a "significant enough difference" is to warrant a tag, then who or what does? (My point here being this proposal seems like a reversal of your earlier approach logic - what if I only have and can test 2.7, not 2.6?)

A post on another meta raised the issue that I did in the earlier question you linked to - if the question isn't version function specific, it should only have the generic language tag. Otherwise the version tag becomes meaningless unless you are already familiar with what changed when.

As blah238 points out in his answer to that other question (and provides several relevant links), different SEs have different approaches to version tags. SuperUser said two Firefox tags are plenty. StackOverflow had a resounding no to that idea. I don't want to regress this too far back to a version tag debate - that's what my question was for, and this one is specifically about Python, though it's obviously rooted in the larger question.

I do agree with the formatting consistency improvements (hyphens and dots). But as mentioned above, I can't speak to which versions justify their own tag vs being part of a parent version as a synonym. I also don't think python general and python version tags on the same question is a good way to go. I'm already sick of seeing arcgis version only (because I don't follow every single version, just desktop), and it still feels very redundant to have both desktop and version tags on a question (though I understand the logic and don't necessarily disagree with it).

Related question: Is there a default assumption as to a version of Python? which also links to the Python tag Wiki on SO, which basically states no version tag preferable, version family tag if needed (#.x) or version tag if it's really that specific. Note that the Wiki does advocate use of both general and version tag on the same question, which differs from my opinion in the previous paragraph. However the difference is the version is only applied to cases when needed and not to every question where asker is using that version. In theory/my opinion this produces much less tag redundancy and increases the value/specificity/usefulness of the version tag.


Here at GIS SE, I think our python-* requirements are, and are likely to remain, more modest than at Stack Overflow.

Once we know that a Python spatial library is being used, then the key remaining thing to know is whether Python 3.x or Python 2.x is involved, because the former is not backwardly compatible to the latter.

Despite and having proved "popular enough" to justify their existence, I think there is very little between those versions.

Earlier in the life of GIS SE almost all questions referred to Python 2.x. However, I suspect a similar or greater number of users here use Python 3.x nowadays. Consequently, I think it is worth streamlining Python tagging here while retaining recognition that there is a significant difference between Python 2.x and 3.x when used with spatial libraries.

I propose:

  1. Make and synonyms of
  2. Leave the tag in place but suggest via its tag wiki that or should be used in preference, especially when you know/suspect that it may make a difference to potential answerers (who may want to run tests with whichever major release they have installed)
  3. Encourage use of and by picking up on whether the one being used is already known (or needs to be known) during the question review stage
  4. Not making any dot release tags for Python like python-3.4

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .