[Python-Dev] [Python-3000] Warning for 2.6 and greater (original) (raw)

Anthony Baxter anthony at interlink.com.au
Fri Jan 12 02:12:18 CET 2007

On Friday 12 January 2007 06:09, James Y Knight wrote:

On Jan 10, 2007, at 6:46 PM, Benji York wrote: > Paul Moore wrote: >> How many other projects/packages anticipate not migrating to >> Py3K, I wonder? > > I certainly can't speak for the project as a whole, but I > anticipate a fair bit of work to port Zope 3 (100+ KLOC) to > Python 3.0.

I (another Twisted developer, among other hats I wear) am also very worried about the Python 3.0 transition.

I'm plan to try and make the transition as painless as possible. A goal I have is to try and make it possible to write code that works in both 2.6 and 3.0. Obviously 2.6 will be backwards-compatible with previous versions, but I'd like to see it get either a command line option or a from future statement to enable compatibility with 3.0-isms, like the dict.items change.

If the goal is really to have Py 3.0 be released later this year,

The goal is to have a first alpha sometime this year - there is absolutely no chance of a 3.0 final this year.

Basically: my plea is: please don't remove the old way of doing things in Py 3.0 at the same time as you add the new way of doing things.

If there was a way to make 2.6 as compatible as possible with 3.0, would this make life less painful? Obviously there'd have to be breakages in a backwards direction, but I'd hope it would make it easier to go forward. Some things should also be OK to backport to 2.6 - for instance, I can't see an obvious reason why 2.6 can't support "except FooError as oopsie" as an alternate spelling of "except FooError, oopsie".

Similarly, where the stdlib has been shuffled around, there should be shims in 2.6 that allow people to work with the new names.

I don't think waiting for 2.7 to make the compatibility work is a workable approach - we're something like 2.5-3 years away from a 2.7 release, and (optimistically) 12-18 months from a 3.0 final. That leaves a window of 1.5-2 years where we are missing an important tool for people.

[1] Unless of course there's a perfect automated conversion script that can generate the 3.X compatible source code from the 2.X compatible source code.

I doubt that the 2to3 script will be perfect, but hopefully it can get most things. I can't see it easily fixing up things like

check = mydict.has_key ... if check(foo):

This is why I also want to add Py3kDeprecationWarning to 2.6.

On that note, I'd like to see changes like the mass-change to the stdlib in the 3.0 branch that changed raise A, B into raise A(B) applied to the trunk. This makes it much easier to apply patches to both the 3.0 branch and the trunk. Similar changes should be applied to remove, for instance, use of <> and dict.has_key from the stdlib. Simply put, I'd like the stdlib between 2 and 3 to be as similar as possible.

-- Anthony Baxter <anthony at interlink.com.au> It's never too late to have a happy childhood.

More information about the Python-Dev mailing list