[Python-3000] [Python-Dev] What should the focus for 2.6 be? (original) (raw)

Josiah Carlson jcarlson at uci.edu
Thu Aug 24 18:01:27 CEST 2006

"Guido van Rossum" <guido at python.org> wrote:

What I do want to do is:

(a) Add an option to Python 2.6 or 2.7 that starts spewing out warnings about certain things that will change semantics in 3.0 and are hard to detect by source code inspection alone, just like the current -Q option. This could detect uses of range(), zip() or dict.keys() result values incompatible with the iterators or views that these will return in 3.0. But there will be no pressure to change such code before the 3.0 transition, and those warnings will be off by default. (b) Provide access to the new syntax, without dropping the old syntax, whenever it can be done without introducing new keywords, or through future syntax.

Both of these things are also what I want.

But these approaches alone cannot cover all cases. While we can probably backport the new I/O library, there won't be a way to test it in a world where str and unicode are the same (unless your app runs on Jython or IronPython). The str/unicode unification and the int/long unification, taking just two examples, just can't be backported to Python 2.x, since they require pervasive and deep changes to the implementation everywhere.

Another change that is unlikely to be available in 2.x is the rationalization of comparisons. In 3.0, "1 < 'abc'" will raise a TypeError; there's just no way to backport this behavior, since again it requires pervasive changes to the implementation. I know that you are dreaming of a world where all transitions are easy. But it's just a dream. 3.0 will require hard work and for many large apps it will take years to migrate -- the best approach is probably to make it coincide with a planned major rewrite of the app.

Easy change would be nice, but working towards everyone having an easy transition would take quite a bit of time and effort, more time and effort than I think anyone is really willing to put forward.

What I want is for the transition not to be hard. Backporting new modules is one way of doing this, offering an import hook to gain access to a new standard library organization (wxPython uses a method of renaming objects that has worked quite well in their wx namespace transition, which might be usable here), deprecation warnings, future, etc., all of these are mechanisms, I see, as steps towards making the 2.x -> 3.x transition not quite so hard.

Ultimately the features/syntax/semantics that cannot be backported will make the last transition hill a bit tougher to climb than the previous 2.x->2.x+1 ones, but people should have had ample warning for the most part, and I hope won't have terrible difficulties for the final set of changes necessary to go from 2.x to 3.x .

More information about the Python-3000 mailing list