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

[Chris Angelico]

On Sun, Jan 19, 2014 at 12:14 PM, Neil Schemenauer
<nas-python at arctrix.com> wrote:
>  That's
> basically the whole idea of this proposal, the bytes/str change in
> 3.x is the really disruptive one, separate it into separate
> interpreter versions to make porting easier.

It may be disruptive to a whole lot of code that's been happily
oblivious to the whole issue, but it's also central to more and more
of Py3's library. It's going to become increasingly difficult to
backport stuff from Py3 to a system that doesn't have the same
back-end string handling.

If you're prepared to make a whole bunch of incompatible changes to
move to this hypothetical 2.8, why not make all the changes at once?
Unless 2.x will be maintained forever (with a 2.9, a 2.10, and so on),
the changes will have to be made. If it's so costly to make a full
pass over your code to port it to 3.3/3.4/3.5, surely it would be
twice as costly to make that exact same full pass to port it to 2.8,
and then another just the same to port 2.8 to 3.6?

I still maintain that the biggest complaints about the jump from 2.x
to 3.x are largely dealt with by 2.7 and 3.3/3.4. Yes, it's hard to
jump from 2.5 to 3.1, but you don't have to. Just stick with 2.x until
your users are all on 2.7, then strip out all the code that's
supporting pre-2.7 versions. Once you have that, you can start in with
some __future__ directives (division, print_function,
unicode_literals), and start sorting out the bytes/unicode distinction
*at your leisure*. (In some cases, that "sorting out" is simply a
matter of naming. I have some code that reads from a socket, and it's
divided into three parts: first pass works with "data" and handles
TELNET codes, second pass works with "text" and handles ANSI codes,
third pass works with "text" and handles newlines. It's obvious from
the parameter names that the conversion from bytes to Unicode has to
happen between the first and second passes.) Then, when you finally
come to port it to 3.x (which mightn't be for another however-many
years, when 2.7's python.org support finally ends, or it might be even
later, when RHEL stops shipping patches, or it might not even be then
- code doesn't stop working just because it's not supported), you make
the jump to whichever version is most convenient. Currently, I'm
seeing 3.3 as easier to jump to than 3.2 (eg the redundant
compatibility notation u"str" is available), and 3.4 is getting some
more on that front; maybe some features won't make it into 3.4 so
they'll be in 3.5. And maybe it'll be 3.7 that you jump to. That's not
a problem. Whatever version you port it to, you make *one* assault on
your code, and there you are, taking advantage of exactly as much of
3.x as you feel like, and it's all working.

ChrisA