<br>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.0 at all -- it's about 2.6 and later. It's about how we get Python
2.x to 3.0, and howmuch of 3.0 we put into 2.6 and later.<br><br>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):
<br><br> 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.<br><br> 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.<br><br> 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.
<br><br> 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.
<br clear="all"><br>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.)<br><br>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.)<br><br>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)?
<br><br>
-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!