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

James Y Knight foom at fuhm.net
Fri Jan 12 06:12:34 CET 2007


On Jan 11, 2007, at 8:12 PM, Anthony Baxter wrote:
> I'm plan to try and make the transition as painless as possible.

I'm glad to hear it.

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

Duly noted.

>> 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?

At the risk of repeating myself:

it's *all* about the overlap between a new way of doing things being  
added and the previous way being deleted. The overlap that's  
important here isn't necessarily version numbers, but *time*. Time- 
since-release correlates directly with the installed userbase of a  
version of python. I'm supposing the plan is for a nearly- 
simultaneous 2.6 & 3.0 release (true?). Then, it doesn't really even  
matter if 2.6 achieves perfect forward compatibility with 3.0, it's  
too late. 3.0 is out, and if I want to be compatible with it, I'd  
then have to then require 2.6+. But as 2.6 was just released, I can't  
require it: most people won't have it installed, and abandoning those  
users is simply not an option. I need *time* between the addition of  
the new API and the deletion of the old.

When Python 3.0 is released, unless it comes with prominent warnings  
saying "nobody should actually use this, don't try to make your code  
run on it, if you run this program all your friends will laugh at  
you.", early adopter users are going to want to use 3rd party  
software with Python 3.0. If my only choice at that point is to tell  
these people "sorry, no, it's simply impossible to support Python 3.0  
with a reasonable amount of effort, while still keeping compatible  
with older Pythons that most users still have", that is not a happy  
situation. I'd like to avoid this situation.

Of course, if 2.6 really is going to be practically identical to 3.0,  
except that 3.0 will have removed a bunch of functionality, well,  
then there's absolutely no reason for *anyone* to use 3.0: the only  
major difference is that nothing can run on it. If that's how things  
will be, is there even any point in releasing 3.0? What good is it?

> Obviously there'd have to be breakages in a backwards direction,

I fail to see why this is obvious. Can't 3.0 be content with only  
removing syntax/features/APIs which can already be replaced by using  
a newer, better thing that already exists in Python 2.4? There's  
plenty of that to do! Py 3.0 can also deprecate a whole new pile of  
stuff to be removed in 3.2, and add a bunch of awesome new features.  
That's great, no objection. But *some* time between addition of new  
feature and removal of old feature, please?

> I don't think waiting for 2.7 to make the compatibility work is a
> workable approach -

Well, yes, that would, of course, be even worse.

> 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.

This suggests an intriguing idea: require all the high level modules  
in the stdlib in python 3.0 to continue to be compatible with Python  
2.5. If the developers of python are forced to make their own code  
also work with both 2.5 and 3.0, I think any poorly conceived  
bidirectionally-incompatible changes will be quickly rejected. :)

James




More information about the Python-Dev mailing list