[Python-Dev] Python 3000 Process

[Guido van Rossum]

On 3/20/06, BJörn Lindqvist <bjourne at gmail.com> wrote:
> -0 on separate mailing list and PEP numbers.

You seem to be the minority so far...

> Because to much separation between python 2.x and python 3.x makes 3.x
> seem more like vaporware that will never happen (Perl 6).

I'm actually trying to reenergize things to make sure Python 3000 *will* happen.

> I would have
> hoped that the transition to 3.x would be evolutionary in small steps;
> removal of string exceptions in one major release, replacement of
> print with a function in the next and so on.

To the extent possible that's certainly the plan. But there are
certain changes that are too hard to do without introducing a major
incompatibility -- you can't add warnings for everything, especially
not where the semantics of an existing API changes (e.g. range(), or
dict.keys(), or int/int). Future statements don't help for some of
these cases either (especially not for dict.keys() and similar, since
dicts are passed between modules).

> A total redesign from
> bottom up in one release has a very high probability of "failing"
> IMHO.

There's not going to be a total redesign. This is exactly the kind of
misunderstanding that I would like to address by specifying a process
for getting there rather than just starting to discuss features. 3.0
will be the opportunity to radically clean up mistakes I made 16 years
ago, by allowing the language to change backwards incompatibly. It is
*not* intended to be as an invitation to start adding random new
ideas. (In fact, there's something to say for *limiting* Python 3000
to the incompatibilities, and to continue introducing new ideas in
2.x, as long as they don't require incompatibilities beyond the
occasional new keyword, which can be handled with a warning and a
future statement. But that's for the Python 3000 process to be
decided.)

> Or at least very annoying for end users that who to deal with
> two parallel and incompatible versions.

Well that can't be helped, really, unless you want to keep the
language backwards compatible forever, can it? Some necessary changes
*are* incompatible, so they are going to cause some pain during the
transition. The alternative would be years and years of pain as
various changes are introduced in different versions (if we did it all
at once it would *be* Python 3.0 of course :-). Python 3000 hopes to
ease the pain by making it all happen at once (ripping the band-aid
off quickly, so to speak :-) while at the same time giving users a
chance to decide *when* to do it -- since (in my vision, anyway) there
will be a fair amount of maintenance applied to the 2.x branch even
after 3.0 has been released.

> The reality is that
> discussions about python 3000 has a high probability of being a total
> waste of time. I think all those of us who have for lengths argued
> whether lambda should stay or be dropped knows that. :)

Now that sounds like an insult. I hope you didn't mean it that way.

Discussing Python 3000 will *not* be a waste of time. I fully intend
to carry through the changes and release Python 3.0 as I have
envisioned it for a long time. If anything's a waste of time, it's
discussing random Python 3000 proposals without having a good process
in place first. That's what I want to change right now.

Barry, if you could create that mailing list, please?

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