[Python-Dev] [Python-3000] Warning for 2.6 and greater

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