[Python-Dev] Python 3000 Process

Guido van Rossum guido at python.org
Mon Mar 20 05:30:13 CET 2006

I see increased activity related to Python 3000. This is great, but
there is some danger involved. Some of the dangers are: overloading
developers; setting unrealistic expectations for what can be
accomplished; scaring the more conservative user community; paralyzing
developers who can't decide whether to wait for Python 3000 or not.

I'd like to address all these issues, but it may be better to first
spend some time on creating a more streamlined process. Perhaps it's
finally time to introduce a separate mailing list? If people agree,
let's call it python-3000 at python.org. For many developers this won't
make much of a difference (since they'll subscribe to both lists), but
it will give people who are only concerned with Python 2.x a way to
opt-out, and perhaps more importantly, it will make it clear whether
any particular proposal is intended for Python 3000 or for Python 2.x.

I don't want to encourage people who are only interested in Python
3000 to opt-out from the 2.5 python-dev list, since Python 3000 is not
being developed in a vacuum. It must be "a better Python" and that
means it is informed to a large extent by recurring issues on
python-dev (and c.l.py!).

The mailing list is only a small part of the new strategy. We need to
start deciding on important meta-issues like:

- What's the timeline? I don't expect to be setting a schedule now and
sticking to it for the next five years. But we owe everybody out there
who is watching some clarity about when Python 3000 can be expected,
and how we plan to get there; there are widely differing estimates of
how long it will take, and I don't want to scare users away or cause
developers to hold their breath waiting for it (some of which I
imagine is happening with Perl 6).

- What's the upgrade path? Do we provide a conversion tool, or a
compatibility mode, or both, or what? Will it be at all possible to
write code that runs in Python 2.x (for large enough values of x) as
well as in 3.0? This also touches upon the issue of parallel releases
of Python 2.x and 3.x. My personal expectation (contrary to what MvL
said recently) is that there will be several 2.x releases issued even
after 3.0 is out; possibly 3.0 and 2.6 may coexist, and 2.7-2.9 may
continue to evolve 2.x while 3.x is maturing. I've seen this used
successfully in Perl (with 4->5) and Apache, and closer to home in
Zope. Again, this is important in the light of how the transition is
perceived in the world outside python-dev.

- Will we do a grand library reform at the same time? Personally I see
that as quite a separate issue; apart from some specific things like
the stdio redesign, we could start the library reform in 2.6, or
post-3.0, depending on how much energy there it.

- What's the implementation strategy? I've started a branch where I
plan to do some weeding out;  but I've already found that the large
amount of legacy code makes the weeding difficult. I may yet decide to
switch to a sandbox model where only new code or carefully modernized
old code is added (this is how Zope 3 was developed).

- What's the procedure for proposing and new features? It may be time
to start a new series of PEPs that focus exclusively on Python 3000.
I'd like to reserve the numbers 3000-3099 for meta-PEPs (e.g.
addressing the above questions) and 3100-3999 for feature PEPs.

Please don't respond with answers to these questions -- each of them
is worth several threads. Instead, ponder them, and respond with a +1
or -1 on the creation of the python-3000 mailing list. We'll start
discussing the issues there -- or here, if the general sense is not to
split the list.

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

More information about the Python-Dev mailing list