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