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

[Stephen J. Turnbull]

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.