Over on python-dev a discussion kicked up over what to do about backward-incompatible changes against Python 2.7 in the name of fixing consistency. The suggestion seemed to be for a Python 2.8, but that is simply not going to happen. I think the reason the idea of Python 2.8 even came up is because I don't think people in general realize how python-dev views the latest and upcoming releases of Python, so I just wanted to clarify this point for the general community.
For as long as I have been involved in Python's development (joined python-dev in June 2002), there has always been a maintenance version and an in-development version. When a version of Python is released it immediately becomes the maintenance version. This means no backwards-incompatible changes unless it is deemed a severe bug. The next version of Python after a release that is started is the in-development version which gets new features, fixes that break compatibility, etc. So when Python 2.6.0 was released it became the maintenance version and Python 2.7.0 became the in-development version. It's essentially all about one version succeeding another.
This is exactly the same for Python 2.7/3.2 from the perspective of python-dev. When Python 2.7.0 was released it became a maintenance version and Python 3.2 became/continued to be the in-development version (we also have Python 3.1 under maintenance, but that is inconsequential to this discussion). To python-dev the difference between the "2" and the "3" in "2.7" and "3.2", respectively are superficial form a policy perspective; Python 2.7 is just another maintenance version of Python just as Python 3.2 is just another in-development version. Yes, the backwards-incompatible changes from Python 2.7 to Python 3.2 are bigger than what people are used to for Python, but our development policies are no different than if we were talking about Python 2.6/2.7 instead of 2.7/3.2. Sure Python 2.7 has some consistency issues, bugs, etc. that would benefit from some backwards-incompatible fixes, but so did every other version of Python ever released. And those fixes are going into Python, they just happen to be going into a version of Python with the number "3" as the leading digit in the version number instead of a "2". If you simply can't get around the version number differences, just view Python 2.7 and 3.1 as two branches in version control that converge at Python 3.2.
Which is why the concept of a Python 2.8 coming from python-dev will never happen. Going backwards to insert an in-development version at this point between Python 2.7 and 3.2 is ludicrous and goes against our development process/policy. Yes, for a time we had 2.6/2.7/3.0/3.1 under development at once (and it was a horrendous pain in our collective ass to manage all of that), but that time has passed. We have moved on to only one in-development version and that's Python 3.2. We are not going back to that crazy parallel maintenance (I would wager even if Python 4 ever happens it was such a time sink).
If people want to makes changes to the Python 2.7 code base which are backwards-incompatible in the name of making it more consistent, fixing bugs, or whatever, then fork the code.
Yes I said "fork"; that "dirty" four letter word that starts with "F" and ends in "K". In this case it's not a big deal as what is being discussed is simply bugfixes and not a divergence of features. Python-dev will never sanction a Python 2.8, but if someone decided to clean up some things and release should-have-been-python 2.8 that focues solely on backwards-incompatible bugfixes and consistency issues then that's fine by us. As long as it is obviously not from python-dev then we have no problem with it.
A hypothetical version of Python that is just fixing bugs that python-dev will not to fix for policy reasons is not going to fracture the community like a fork of an in-development branch that takes the project in a new direction. We will continue to add cool new things into Python 3 that people will want so people will want to stick with python-dev's version of Python. Plus the version from python-dev happens to be Guido's version of Python which makes it the most Pythonic version =). Plus plenty of people will simply want to stick with the sanctioned versions of Python simply because they are as official as you can get. You also have all the other Python VMs (Jython, IronPython, PyPy) following what python-dev releases and not some fork. But for those that really love CPython 2.7 but want its kinks ironed out, your option will be to do a fork, and from python-dev that's okay as it won't cause the community to fall apart and have to choose sides.
But obviously I think everyone should just upgrade to Python 3.2 when it comes out instead of worrying about keeping Python 2.7 alive past its prime. =) Regardless, Python 2.8 it never happen.
