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

[Guido van Rossum]

On 8/23/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> Specifically his reponse to the "Here's my suggestion:" paragraph.
> Unless I completely misunderstood his response, and his later asking
> whether I want to help author the transition PEP (presumably for at
> least dict.keys(), bur more likely from 2.x to 3.x), I can't help but
> believe that he also wants at least an attempt at some gradual change
> for users with cold feet about breaking everything in one go.
>
> Also, in the talk he gave at Google on July 21, somewhere around the
> 7:45-11 minute mark, he talks about how 3.x features are to be
> backported to 2.7 or so, specifically so that there is a larger subset
> of Python that will run in both 2.x and 3.x .  Smells like an attempt at
> gradual migration to me.

Since you're trying to channel me, and I'm right here listening to you
(and annoyed that you are wasting my time), I need to clarify. What I
*don't* want to happen is that Python 2.6 2.7, and so on keep changing
the language from under users' feet, requiring constant code changes
to keep up, so that by the time the 2.9 -> 3.0 transition comes it
will feel pretty much the same as 2.4 -> 2.5. That would be bad
because it would mean that for every transition users would have to
make a lot of changes. (Pretty much the only changes like that planned
are increasing deprecation warnings for string exceptions, and making
'with' and 'as' unconditional keywords in 2.6.) 3.0 (or 3.2) will feel
like a big change and will require a combination of automatic and
manual explicit conversion, sometimes guided by warnings produced by
Python 2.x in "future-proof-lint" mode (see (a) below).

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.

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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)