[Python-Dev] PEP 0404 and VS 2010

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.


More information about the Python-Dev mailing list