Benjamin Kaplan, 27.01.2010 22:25:
When Python 2.6 came out, Jython was still on 2.2. The difference
between 2.2 and 2.6 is almost as big of a difference as between 2.6
and 3.0.
From an implementors point of view, it's actually quite the opposite. Most
syntax features of Python 3 can be easily implemented on top of an existing
Py2 Implementation (we have most of them in Cython already, and I really
found them fun to write), and the shifting-around in the standard library
can hardly be called non-trivial. All the hard work that went into the
design of CPython 3.x (and into its test suite) now makes it easy to just
steal from what's there already.
The amount of work that the Jython project put into catching up from 2.1 to
2.5/6 (new style classes! generators!) is really humongous compared to the
adaptations that an implementation needs to do to support Python 3 code. I
have great respect for the Jython project for what they achieved in the
last couple of years. (I also have great respect for the IronPython project
for fighting the One Microsoft Way into opening up, but that's a different
kind of business.)
If there was enough interest from the respective core developers, I
wouldn't be surprised if we had more than one 'mostly compatible'
alternative Python 3 implementation in a couple of months. But it's the
obvious vicious circle business. As long as there aren't enough important
users of Py3, alternative implementations won't have enough incentives to
refocus their scarce developer time. Going for 2.6/7 first means that most
of the Py3 work gets done anyway, so it'll be even easier then. That makes
2.6->2.7->3.2/3 the most natural implementation path. (And that, again,
makes it a *really* good decision that 2.7 will be the last 2.x release line.)
Give the package maintainers time to update. There were some pretty
big changes to the C API. Most of the major 3rd party packages like
numpy and MySQLdb have already commited to having a Python 3 version.
They just haven't gotten them out yet.
I second that. NumPy has already announced that they'll rewrite some of
their code in Cython to make it more maintainable and portable (and to
simplify the port to Py3, I guess). Other projects will equally well find
their ways to get their code ready. It's just a matter of time. I think
there's enough pressure on the maintainers by now (both from users and from
personal pride) to consider their packages tainted if they aren't portable
enough to run on all major (C)Python versions (and Py3.1 certainly is one
of them), even if they don't use them themselves. That appears to be an
impressively good incentive.
Stefan