[Python-3000] Py3.0 impacts on Py2.6
talin at acm.org
Thu Mar 15 00:12:31 CET 2007
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.
More information about the Python-3000