[Python-Dev] Continuing 2.x

[Brett Cannon]

2010/10/28 Kristján Valur Jónsson <kristjan at ccpgames.com>:
> 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?
>

And all of that work has been appreciated obviously (in case that
wasn't obvious =).

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

Which is the correct 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.

Well, they are welcome, just in Python 3.2 instead of Python 2.7 (when
they apply to Python 3.2 in the first place). We have had a bugfix
version in development as well as the new features version for ages.
It just so happens that a bunch of people have not decided when they
plan to switch to the new features version yet.

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

It's called a fork. I realize you are trying to avoid that "dirty"
word, Kristján, and I appreciate it, but you are describing a fork.
Python 2.7 is the last sanctioned version of the Python 2.x series,
period. Any non-bugfix changes will not go in there as policy
dictates. And with there being no way Python 2.8 will happen (I know
we as a group have said "slim chance" since Python 3.0 came out,
uptake of Python 3 is such I am willing to personally say "never" for
a python-dev sanctioned Python 2.8), that means it will take a fork,
whether it be internal to CCP or public somewhere, it will still be a
fork.

And as everyone has said so far (and with which I agree), that's fine.
As long as it is not called Python 2.8 -- EVE-Python 2.8 or some Monty
Python reference -- then that's fine. And as pointed out by folks,
once Hg kicks in and we have user repos you can even host it on
hg.python.org yourself to give it some semblance of authority if you
want.

I understand the desire to have the final version of the Python 2.x to
be as perfect as it can be, but that will never happen. Every release
of Python is imperfect. There will always be mistakes we made that
require incompatible changes to rectify. It's life and that's just a
part of software development.

I think people need to stop viewing the difference between Python 2.7
and Python 3.2 as this crazy shift and view it from python-dev's
perspective; it should be viewed one follows from the other at this
point. You can view it as Python 3.2 is the next version after Python
2.7 just like 2.7 followed to 2.6, which makes the policies we follow
for releases make total sense and negates this discussion. It just so
happens people don't plan to switch to the newest release immediately
as the backward-incompatible changes are more involved than what
people are used to from past releases.

So to summarize, we are not changing our minds on Python 2.8; there
won't be a Python 2.8 sanctioned by python-dev ever. Python 3.2 is the
next version after Python 2.7 and the typical policy of bugfix/feature
release rules apply as normal. People who want to iron out some
inconsistencies in Python 2.7 by forking it and renaming it to prevent
people from thinking python-dev made the release are welcome to and
there won't be any ill will or hard feelings if that does occur.

-Brett

>
> 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).
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>