"Guido van Rossum" <[EMAIL PROTECTED]> 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 . - Josiah _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
