[Python-Dev] Continuing 2.x

[Kristján Valur Jónsson]

Hi all.
This has been a lively discussion. 
My desire to keep 2.x alive in some sense is my own and I don't know if anyone shares it but as a member of this community I think I'm allowed to voice it.  So, just to clarify my particular position, let me explain where all this comes from.

I am the maintainer of a private fork of Stackless Python 2.7, used by EVE Online.  Since I started doing this, we have moved from version 2.1 to 2.3, 2.5 and finally a few months ago to 2.7.
Python is embedded into the C application so we use the C API extensively.
For a long while now I have been contributing a few improvements and patches to both the interpreter core and the standard library.  These are changes that stem from solving particular problems that we face in our rather extensive use of python, and range from crash bugs to performance optimizations as well as the occasional feature.
Usually the process is something like this:
1) We identify a problem that needs fixing.
2) We then spend some development effort on finding the right fix for it.
3) We then reflect:  Shouldn't this be contributed back to standard Python? That means
  a) others will benefit
  b) It reduces the diff of our fork from the central branch.
4) I spend some time reworking the change, submit a patch to the 2.x version that eventually  gets accepted or rejected by the community
5) And in the last few years, should a change be accepted, I am then often asked port the change to 3.x, which I normally do.  (and sometimes even correctly using svnmerge...)
This has been a happy and a personally fulfilling process, because who doesn't like to contribute to Python?

Now, of late some of this has changed.   Changes, (except those that pass as "bugfixes") are no longer accepted into the 2.x branches.  Should the change apply to 3.x, then I have to locally port it to 3.x, and submit it to that branch.  Some changes don't really apply to 3.x at all and have no place to go.  So people using a platform similar to mine won't benefit.
The result is that there is a much higher threshold for any of our improvements to make it back to the community and much less personal pleasure derived from it. 

What finally drove me to write the original post, was that working with the new bytearray and memoryview object in 2.7 made me realize that they don't interoperate with other classes in a natural way and so nullify their advantages.  My straightforward patches to 2.7 to remedy this situation (issues 10211 and 10212) were met with the usual "it's not a bugfix" reply.

So, I'm frustrated.  I work with 2.7 on a day to day basis, and will continue to do so for quite some time.  It's a great product with some shortcomings, and I'd like to contribute to it but such contributions aren't welcome anymore.

I'm not sure what I'm actually proposing.  But I certainly wasn't thinking of a new "fork" of python.  And not a new version 2.8 that gets all new 3.x features backported.
I'm more thinking of a place where usability improvements, C API improvements, performance improvements, Library improvments, can go.

Cheers,

Kristján

-----Original Message-----
From: python-dev-bounces+kristjan=ccpgames.com at python.org [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf Of Barry Warsaw
Sent: Friday, October 29, 2010 0:04
To: python-dev at python.org
Subject: Re: [Python-Dev] Continuing 2.x

Who is the target audience for a Python 2.8?  What exactly would a Python 2.8 accomplish?

If Python 2.8 doesn't include new features, well, then what's the point?
Python 2.7 will be bug fix maintained for a long time, longer in fact than previous Python 2 versions.  So a no-feature Python 2.8 can't be about improving Python 2 stability over time (i.e. just fix the bug in Python 2.7).