[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