[Python-ideas] Create Python 2.8 as a transition step to Python 3.x

[Steven D'Aprano]

On Fri, Jan 17, 2014 at 09:22:19PM -0600, Neil Schemenauer wrote:
[...]
> Here is a far out idea to make transition smoother.  Release version
> 2.8 of Python with nearly all Python 3.x incompatible changes except
> for the bytes/unicode changes.  This could include:

It's hardly a "far out" idea. You're not the first to suggest this. 
There are many people asking for -- demanding, almost -- a Python 2.8 
that provides only the subset of Python3 that they are interested in and 
gives them an excuse to avoid migrating for another three or five or ten 
years.

Because really that's what 2.8 is all about -- providing people an 
excuse to put off migrating for a bit longer. But the thing is, they've 
still got a good three or more years before 2.7 goes into "security 
patches only" mode, and likely years more before it becomes 
unmaintained. And then there's third-party support from companies like 
RedHat. They will continue supporting Python 2 until end of 2023:

https://access.redhat.com/site/support/policy/updates/errata/#Life_Cycle_Dates


I wonder whether the 2 to 3 transition might not have been handled 
better with a long-drawn out process of slowly adding 
backwards-incompatible changes a few at a time? This is like the old 
chestnut about whether it is better to ease yourself into a really cold 
swimming pool a little at a time, or get it over with in one go by 
diving in. In both cases, you have pain, is it better to have a lot of 
pain that only lasts a short while, or a little bit of pain that goes on 
and on and on and on...? I think that had Python decided to add 
backwards-incompatible changes a few at a time, people now would be 
complaining about that and demanding that there be a once-off cutover 
version.


> - removal of 'apply', 'buffer', 'callable', 'execfile'

callable is back in Python 3.3.


> Problems with this idea:
> 
> - it would be a huge amount of work. [...]
>
> - if people install this new version of Python as the default, old
>   scripts and programs will break. [...]

- It gives people an excuse to avoid migrating, and as sure as the sun 
rises in the east, will lead to people calling for Python 2.9 a few 
years from now.


> An alternative approach to producing Python 2.8 would be to start
> with the Python 3.x latest branch.  Modify bytesobject and
> unicodeobject to have as close to Python 2 behavior as practical.
> 
> A-journey-of-a-thousand-miles-begins-ly y'rs

The journey *already began* back in Python 2.6. Python 2.6 is the start 
of the journey, it introduces dict views, next() builtin, from 
__future__ absolute_import print_function and unicode_literals, and 
probably more that I have forgotten.

So really, people have had 2.6 and 2.7 to ease the transition from 2.5 
to 3.x. If they haven't taken advantage of that, what makes you think 
that 2.8 and 2.9 will convince them to migrate?

But you don't have to believe me. Python is open source. Feel free to 
fork it and backport whatever features you like, and see how much 
interest you get from the wider community. Just don't call it "2.8", 
that sends the wrong message and is a pretty rude thing to do given that 
the core developers have said that they will not make a 2.8:

http://www.python.org/dev/peps/pep-0404/

Just because there will not be a CPython 2.8 doesn't mean you can't go 
ahead with your plan to backport 3 features to a 2 base. Just call it 
something else.


-- 
Steven