Neil Schemenauer writes:
On 2014-01-18, Terry Reedy wrote:
On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
For application code, why does it need to be ported.
Unless Python 2.x is going to be maintained in perpetuity then code will have to be ported. This point seems obvious to me.
But it's not even true. Python 2.7 is a Turing-complete language, it can do anything that any language can do as an abstract computation, and 2.7.6 has extremely few bugs and sufficient bindings to OS facilities to do almost anything in practice as well. It's a pretty darn good language. Most Python 2 programs will probably be abandoned before Python 2.7.6 will need additional maintenance beyond what is already provided by various OS distros.
I disagree. The amount of Python 2 code that exists exceeds the amount of Python 3 by orders of magnitude. That existing codebase either stops evolving and stays Python 2 forever
But "stays Python 2 forever" != "stops evolving". There is absolutely nothing to stop a Python 2 program from evolving dramatically over the indefinite future, any more than sticking to C89 stops a lot of C programs from evolving. I don't see any real reason to suppose that most applications will find a true need to evolve in directions that Python 2 doesn't support for quite a while.
A Python 2 fork is going to happen whether the PSF blesses it or not, I can't believe that's even a point of discussion.
It's not a point of discussion. In the same sense that COBOL compilers continue to be maintained today, Python 2 was forked long ago. Not only are there non-CPython implementations of the language, every distro (commercial or not) has their own patches (perhaps a null set for Python 2.7.6). That's not going to stop, and as Nick points out Stackless is even likely to add some Python 3 features to their implementation of 2.x. But that's a specialty interest, and not even all Stackless users will necessarily use those features. I doubt many commercial packagers of CPython will have customers interested in them -- the Stackless guys want the Python 3 features for internal use as much as for their clients IIRC.
But a fork of the kind you propose isn't going to happen. Definitely not under the auspices of the PSF, that's been settled with PEP 404. Nor with volunteer labor -- there aren't any volunteers for that. If there were, they would have started long ago. And I don't see a story for a commercial fork, either.
The problem is that there's no "halfway point" here. Porting a program from Python 2 to Python 3 either does not require a fundamental rethink of its internal text processing, or it does. In the former case, 2to3 does a pretty good job, and what's left is a SMOP, mostly to fit appropriate decoding/encoding on to I/O. In the latter case, you've got big problems -- a complete redesign and an audit of all code for conformance to the new design. This is the watershed; there's no way to create a language intermediate between Python 2 and Python 3 so that porting Python 2 to Python-sqrt(6) is half the work, and porting Python-sqrt(6) to Python 3 is half the work.