[Python-Dev] Python-3000 upgrade path

[Thomas Wouters]

I'm sending this to python-dev instead of python-3000 for two reasons: It's
not about features to be added to Python 3.0, and it's not really
about 3.0at all -- it's about
2.6 and later. It's about how we get Python 2.x to 3.0, and howmuch of
3.0we put into
2.6 and later.

So here at PyCon, Guido did his usual talk about Py3K and how it's going to
look. He also covered the tool he's writing to do the necessary syntactic
translations, and short bits about how to write code to accommodate the
other changes. One thing Guido didn't cover -- because it isn't his area of
expertise and (correctly) expects others to step up and do it -- is the
upgrade path for third party Python applications and libraries. I happen to
care a lot about that, and so do a few other core Python developers, and we
*will* make it happen in the smoothest way possible. We could use some
community guidance on this, though. Here's my current thinking on the
subject (and I talked about this with a couple of different people at the
conference and in email):

 1) Anything we can backport from Python 3.0 to Python 2.6 without breaking
existing code, will be backported. So far, this means all the new features.

 2) A few of the things going away in 3.0 will be warned about in 2.6 by
default: things that have had better alternative for ages and are generally
bad: backticks and input() are the only ones that come to mind right now.

 3) The rest of the things that will change or go away in 3.0 *and* have
alternatives in 2.6 will be warned about optionally. Neal is rewriting the
warnings module to C, which should speed up warning generation a lot, and if
necessary we'll use a global 'warn-for-py3k' flag to reduce the overhead for
these warnings to the absolute minimum.

 4) The new features of 3.0 that we can't backport (things changing
semantics, instead of being added or going away) will be made available in
2.6 (as much as possible), using future statements. Right now, I cannot
think of a single thing that cannot be made available that way. They will
be, in essence, backward-compatibility hacks, but they'll work and the
performance impact will be minimal.

Of course, 4 is somewhat of a sweeping statement, even with the
parenthesised reservation, considering some of the 3.0 features haven't been
implemented yet. I'm pretty confident we can do this without comprimising
3.0, though. If we cannot, we might need to add an extra 'migration feature'
in Python 2.7, or 2.8 or even 2.9 (but as it is now, I'm not sure that's
specifically necessary. We may still want to release Python 2.7 and later
for other reasons, of course.)

The end result will be that you can write your Python code so it works in
2.6-or-later and 3.0, or -- just like now -- in 2.x-or-later (where 'x'
depends on the features you use) but not 3.0. If you write careful code, you
may get away with writing 2.2-or-later code that can be run in 3.0 with a
single translation run. It will be fairly unlikely you can write code for
2.5-or-earlier *and* 3.0 without using the translation step, unless you live
in a world blissfully unaware of anything non-ASCII. In any case, while we
aren't working to make that possible, we certainly won't go out of the way
to prevent it (but there still won't be any compromises in the 3.0 language
just for code compatibility.)

As I said, I've talked with a few people about this, both python core
developers and people who develop their own software. I would like to hear
from people who have concrete doubts about this upgrade path. I don't mean
doubts about Python 3.0 -- this mail isn't about 3.0 at all, and I can only
suggest you try out the py3k branch when the dubious feature(s) are
implemented. I also don't mean doubts about how we're going to keep the
performance impact minimal or how we're going to handle dict views and what
not. I mean doubts about this procedure of having transitional releases
between 2.5 and 3.0, and the *community* impact of 2.6+ and 3.0 this way.
One thing in particular I wonder about is the warning about mixing tabs and
spaces. Should it be in category 2) (on by default) or 3) (still off by
default, but part of -Wpy3k)?

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20070225/c498f01d/attachment-0001.htm