[Python-Dev] PEP 0404 and VS 2010 (original) (raw)

Chris Angelico rosuav at gmail.com
Fri Nov 22 12:56:20 CET 2013

On Fri, Nov 22, 2013 at 10:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

A few folks overreacted in their concern about the community confusion such a move would inevitably create - anything called "Python 2.8" is going to give the impression that we've changed our mind about 2.7 being the last feature release in the 2.x series, even if it has the word Stackless in front of it.

From what I understand of the discussion, the problem is only because it's the specific value "2.8", which could plausibly be a Python version number. Calling it "Stackless Python 10" wouldn't cause confusion (don't remember who suggested that), as it's clearly not part of the regular Python versioning system - you could say "Stackless Python 10 is code compatible with Python 2.7" and there'd be no confusion. But if, say, Red Hat release something called "Python 2.4.6-rhel", I would expect it to be entirely compatible with a python.org Python 2.4 release, possibly with some additional bugfixes; it says "2.4" in it, so I'm not going to go dig through its docs to figure out what my code will run on. I certainly wouldn't expect it to be "2.2 built with a new compiler", or "2.7 with additional libraries added", or anything. It's all about how it reads at first glance.

In my personal opinion, I would very much like to see the 2.x line not be supported indefinitely. Why are so many people still using it? Because the impetus to shift is weaker than the inertia to stay. How will that be changed? By strengthening the need to move on. If anyone pledges to support a 2.x variant for the next couple of decades, then python-list will have to deal with people not knowing (and not saying) whether they're on 2.x or 3.x for probably another 30 years or more. I'd rather be able to stop warning people about input() and non-Unicode strings and from future import division.

ChrisA

More information about the Python-Dev mailing list