[Python-3000] Py3.0 impacts on Py2.6

[Talin]

Raymond Hettinger wrote:
>>> I would like to additionally address the idea of "fixing" things 
>>> with a -py3k flag.  Many (most) Python programmers will not migrate
>>> all of their stuff to 3.0 overnight . . .
> 
> After hearing Guido's talk at PyCon, ISTM that Py3.0 will be accepted
> widely and gracefully on its own merits. However, I sense in this forum
> a strong inclination to hedge bets by monkeying with Py2.6 in ways
> that go beyond the -py3k flag or backporting compatible new features.
> 
> It is important to not delude ourselves about the role of Py2.6.
> We don't get to decide that -- the users do.  We all know, it is a
> big deal for a shop to migrate from 2.5 to 2.6 (reloading/rebuilding
> third-party and homegrown modules/extension, suppressing/addressing
> warnings, code updates, etc).  Accordingly, users will NOT upgrade 
> unless Py2.6 is BETTER than Py2.5.
> 
> In our shop, if Py2.6 is slower or is just a pile of deprecations
> and warnings, then we will likely limit the upgrade to just a single
> person who can use it as tool to transition our code and third-party
> tools to Py3.0 when the time comes.  The rest of the shop will go 
> straight from Py2.5 to Py3.0 unless Py2.6 shows some compelling 
> advantage over what we have now.  If Py2.6 is to be accepted, it 
> needs improvements, not second-class status as a stepping stone.
> It should be the best of the 2.x series, not a dumping ground for
> transitional stuff; otherwise, why bother with it at all?

I think you make good points; However I think that the backporting of 
Python 3000 features may be sufficient to give Python 2.X users a 
compelling reason to upgrade to 2.6.

Here's the way I see it: The 'official' reason for the existence of 
Python 3000 is to allow us to go back in time and revisit some early 
design decisions, which cannot be changed in 2.X because they would 
cause backwards incompatibility.

However, many of the 3000-series PEPs are not of this nature at all 
(including all of mine.) Instead, they are PEPs that propose dramatic 
new features, which have little or no backwards-compatibility impact.

I think that part of the reason for this is that all of us who live in 
the software world have certain expectations about what happens when a 
major release number gets bumped. For any given piece of software - 
especially in the commercial world - when a major version number bumps 
from "2" to "3" we expect a whole boat load of new and interesting 
functionality. We as customers would be disappointed if Photoshop 7 was 
simply Photoshop 6 + bug fixes. (Although perhaps it would be a better 
world if we didn't - but that's another topic.)

The fact that we've used the name "3000" instead of "3" further adds to 
the "marketing hype" that feeds that expectation, that Python 3000 is 
going to be a "brand new, radically better" Python.

I think that there's also a perception in the development community that 
the Python 3 series is "more open" to radical feature suggestions.

The result of all this is that a lot of the creative energy that would 
have gone into Python 2.6 has instead been drawn off to Python 3.

Most of the PEPs in the 3000 series could have just as easily been 2.X 
PEPs. Of the PEPs that propose new features (as opposed to removing old 
ones) there's only a few cases, I think, where a PEP is 'enabled' by the 
freedom to break backwards compatibility. What this means to me is that 
many of these PEPs could in fact be backported to 2.6, if it was felt 
useful enough to do so.

Which in turn says to me that the compelling marketing tag line for 2.6 
is "most of the features of Python 3000, but still compatible."

I should also say that I have a slightly different view of the 
relationship between the 2.X series and the 3.0 series. Part of the 
attraction of 3.0 is the opportunity to make a "clean break", unhampered 
by the mistakes of the past. I think that it's good for language 
designers sometimes to be able to stretch out and not be constrained too 
much by the past.

But I don't think that, in the end, there will actually be a "break". 
What I mean is, I think that eventually there will be a convergence 
between the 2.X and 3.0 series. Each subsequent 2.X release will be more 
compatible with 3.0 than the previous ones.

The reason for this has to do with the way that innovation in the 2.X 
series is going to happen from now on: I very much doubt that people are 
going to be innovating new features in 2.X that aren't also going to be 
ported to 3.0; Which means that every change to 2.X is going to bring it 
closer to 3.0 in some way, and there won't be any changes that move 2.X 
farther away from 3.0. So as long as 2.X keeps changing and is not 
entirely frozen, it will gradually become more like 3.0.

The result is, I think, that eventually there will be a smooth 
transition path between the two major versions.

-- Talin