[Python-3000] [Python-Dev] What should the focus for 2.6 be?

[Josiah Carlson]

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

 - Josiah