(Optionally) add Python sub tags to questions

Question

The lack of version tags on some Python questions leads to reviewers having to 'pre-scan' the code to find out if it's Python2.7, Python3, both or neither. This seems strange as, I'd have thought that the question would be tagged with a sub-version if it only works in one. And definitely doesn't allow us to "sorting questions into specific, well-defined categories".

Currently we have 5012 python questions, of these we have 896 python-3.x questions and 682 python-2.7 questions. I can't imagine we have 3434 questions that work in both Python2.7 and Python3, or neither. And so removes the ability to easily sort and identify questions.

I'd like to at times just change the tags when the question is made, but don't know if the community agrees that it's ok to do this. We currently do something like this, however it's if the question has only a Python sub-version, we should add the [python] tag.

Answer 1

The problem you are pointing out, as you very well know, is inherent of Python itself, where a piece of code falls into one of 4 categories, roughly from most common to most rare:

1. Works only in Python 2.7
2. Works only in Python 3.x
3. Works on both Python 2.7 and 3.x
4. Works on neither 2.7 nor 3.x (those are probably very rare)

After some querying on SEDE, I found that the counts for each of the above categories are as follows, based strictly on the questions' respective tags:

Category               Posts 
---------------------- ----- 
1. Python2Tag          680   
2. Python3Tag          878   
3. BothPython2And3Tags 17    
4. NoVersionTag        3390

_{*Note that the numbers from SEDE are slightly lower than the live site's due to only updating every Sunday.}

And your statement becomes incredibly apparent, given the numbers:

I can't imagine we have 3434 questions that work in both Python2.7 and Python3, or neither.

---

Simple answer:

I'd like to at times just change the tags when the question is made, but don't know if the community agrees that it's ok to do this.

I'd like to think that yes, the community in general would agree to (and benefit from) you changing the tags if it is apparent that the code is designed for certain Python version(s). This would be a good habit for all of us to practice in triaging new python questions as they come in.

However, as you can see from the numbers, it would take a very long time to go through over 3000 questions, changing the tags one by one as needed.

---

With that in mind...

I experimented a bit with SEDE to see how many "non-versioned" questions could be version-guessed from, say, comparing posts that use the Python 2.7 print keyword vs. posts that use the Python 3.x print() function (which is one of the most recognizable lexical differences between the two), and that yielded some interesting numbers:

PythonVersion SearchMethod       Posts 
------------- ------------------ ----- 
2             `print` keyword    1196  
3             `print()` function 755
------------- ------------------ ----- 
Total                            1951

Based on this search criteria alone, a significant portion (1951/3390 or 57.5%) could be assumed with high certainty to be specific to either 2.7 or 3.x, and not both. Further refining of the remaining subset could likely yield to some much higher figures...

References:

• Python Tag Filtering by print statements (aggregate)
• Python Tag Filtering by print statements (list)

---

Another possibility?

There is always the possibility of requesting mass updates from Stack Exchange staff, if there is a community consensus (which would be outside the scope of this question) on the method(s) used for deciding what and how to update, as well as the set of affected posts. Site moderators and CMs would have more details on the process.

Answer 2

Phrancis wrote a good answer, but it's a bit long. So I'll add my 2c anyway.

If a question works with one version of Python but not with another, please add the relevant tag the moment you find out. Even if you're not interested in reviewing the question. It makes it easier on the next possible reviewer encountering the question.