9
\$\begingroup\$

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 questions, of these we have 896 questions and 682 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.

\$\endgroup\$
7
\$\begingroup\$

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 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:


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.

\$\endgroup\$
  • \$\begingroup\$ (those are probably very rare). Nope, those are considered broken code. Those get closed instead of re-tagged. \$\endgroup\$ – Mast Sep 13 '16 at 14:51
  • 1
    \$\begingroup\$ @Mast They are not broken. If I want to post code in python-2.6 I can. \$\endgroup\$ – Peilonrayz Sep 13 '16 at 14:56
  • \$\begingroup\$ @JoeWallis Ah, yes, but that one has it's own tag. Perhaps it should be added to the list for completeness sake. \$\endgroup\$ – Mast Sep 13 '16 at 14:59
  • \$\begingroup\$ Of-course there's always the possibility of explicitly specifying it in the question. Which one should do when using an odd version. \$\endgroup\$ – Mast Sep 13 '16 at 15:03
  • \$\begingroup\$ For the sake of the above numbers, I lumped in 2.6 with 2.7 as there were only very few tagged with python-2.6. \$\endgroup\$ – Phrancis Sep 13 '16 at 15:06
  • \$\begingroup\$ @Mast IMO there should just be [python] [python-2.x] and [python-3.x] why are 2.6 and 2.7 special? If you need to say it works on X version of Python2/3, which isn't the latest, then say so in the question. \$\endgroup\$ – Peilonrayz Sep 13 '16 at 15:15
  • \$\begingroup\$ Other 228 use xrange and therefore must be Python 2. data.stackexchange.com/codereview/query/edit/540667 I think a good chunk of this Python 2/3 classification can be done automatically. \$\endgroup\$ – Caridorc Sep 17 '16 at 11:10
3
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

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