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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
