[Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

[Glyph Lefkowitz]

On Nov 3, 2009, at 6:23 AM, Paul Moore wrote:

> 2009/11/3 Raymond Hettinger <python at rcn.com>:
>> In all these matters, I think the users should get a vote.  And  
>> that vote
>> should be cast with their decision to stay with 2.x, or switch to  
>> 3.x, or
>> try to support both.  We should not muck with their rational  
>> decision making
>> by putting "carrots" in one pile and abandoning the other.

> The biggest issue to my mind is that adoption by the ultimate end
> users is significantly hampered by the fact that big projects like
> Twisted, numpy and the like, have no current plans to move to Python
> 3. Even end users with a reasonable level of coding expertise don't
> have the time or resources to offer much in the way of help with a
> port, when the project as a whole isn't interested in starting the
> process.

For what it's worth, the official position of the Twisted project is  
not that we have "no plan" to move to Python 3.  It's that our plan is  
to do exactly as Raymond suggests, and give the users a vote - in this  
case, you vote with your patches :).

We are actively and frequently encouraging our users to contribute  
patches that clean up warnings, which is the biggest impediment to a  
py3 port of Twisted.  Some of you would probably expecting to whinge  
about how people never contribute anything, but actually, users *have*  
shown up and started doing this.  Our biggest problem at the moment is  
that we don't have enough people doing code reviews so the  
contributions are starting to pile up.  As I said in my other message,  
if someone would like to help, signing up to do code reviews would be  
a good way.

Despite this progress, my hope is that there will be a robust 2.x  
series up through 2.9.

For one thing, we have a very long row to hoe here.  The migration to  
3.0 is a long, tedious process with little tangible benefit.  I hope  
that sometime in the next decade Twisted can accelerate the process of  
dropping old 2.x versions, but I seriously doubt we could do a feature- 
complete 3.1/2.6 version.  I get the general impression that a 3.2/2.7  
port would be more feasible; hopefully a 3.3/2.8 would be even moreso.

Also, the benefits of migrating to python 3.x are still negligible, as  
far as I can tell.  On the one hand, you've got a Python with no old- 
style classes and a clear unicode/bytes situation, and that's great.   
On the other hand, you've got NumPy, PyGTK, Unladen Swallow, PyPy,  
Jython, IronPython, and so on and so forth.  Since I started using it,  
the strength of Python has been in its ecosystem, and the 3.x  
ecosystem is not yet viable.

As long as we're tossing out modest proposals here, I still think that  
(as I believe James Knight already proposed) abandoning the current  
3.x branch, backporting everything to 2.7, and continuing forward with  
a migration strategy that introduces individual deprecations every  
major version until 2.x == 3.x is the way to go.  For example, 2.8  
could emit a deprecation warning for every old-style class that was  
defined, 2.9 could emit a deprecation warning for every string  
constant declared without a 'b' or 'u' prefix unless the module in  
question were in "3.x mode" (i.e. no-prefix == 'u').  (I leave the  
determination of whether the parser should be in 3.x mode for a  
particular module as an exercise for the reader, but a 'from  
__future__' import would suffice.)

I realize that there are other issues here, like the C ABI changes  
some NumPy folks have raised.  Also, I'm not planning to actually do  
any *work* on this suggestion, so you can take it for what it is,  
which is to say, armchair quarterbacking.

There have been some other comments in this thread indicating that  
this was not the case because some users indicated that they'd rather  
deal with lots of changes "all at once".  My understanding is that it  
was done this way so that the *developers* of Python could make a  
clean break, and design and implement a new version of Python without  
being constrained by compatibility concerns.  If you can show me an  
actual application or library developer in Python who wanted this one- 
big-jump migration, I will show you a crazy person.

The main reason I want a long 2.x series is that I believe it would  
more easily allow us infrastructure folks to drop support for *older*  
versions.  With this big 2.x->3.x chasm, I can't really see an end in  
sight for Twisted using Python 2.x as its _source_ language,  
translating with 2to3.  Some projects which depend on Twisted and want  
new versions (and security fixes, etc) are going to want Python 2.x  
for a really long time.  Maybe they're just really conservative, maybe  
they don't have a lot of maintenance energy, or maybe they have other  
dependencies which haven't got a port; it doesn't really matter,  
empirically speaking people want older versions of Python.

Keep in mind also that the 2.x translation process is extremely slow  
and results in a clunky development process.  There's no '2to3 -- 
interactive' commandline that lets me type python 2 at a >>> prompt  
and get python 3 results out so that I can try experiments on the 3.x  
interpreter; I have to actually put my experiments into my unit tests  
and wait 10 minutes to see if it works.  It's like writing C++.

With the 2.x series, users and operating systems seem to move on  
fairly rapidly, because dependencies generally continue to work if you  
upgrade just one version.  This isn't quite as formal a requirement as  
I would like (warnings get generated, unit tests fail, things do  
break) but in practice, users can rely on it for most functionality.   
If 3.x could be broken into a series of transitions like that, where  
you can upgrade one version, fix some stuff, then upgrade another  
version, even if you couldn't actually support more than 2 versions at  
once, I think that we could pick up the migration pace to the point  
where we might actually be using 3.x syntax in a few years.  Having a  
2.x series which goes to 2.9 and then stops isn't *quite* the same  
thing as having one that moves over continuously to some 3.x version,  
but it does seem to me that by that point the chasm between versions  
will have narrowed to a crack, and the migration will be a little hop  
over it rather than the currently-required great flying leap.

(To be fair, that leap is not the surface-to-orbit rocket-propelled  
jump that I originally expected it to be.  Still, it's still not a  
small effort, especially if you're interfacing deeply with a lot of I/ 
O APIs.)