On Nov 3, 2009, at 6:23 AM, Paul Moore wrote:
2009/11/3 Raymond Hettinger <pyt...@rcn.com>:
In all these matters, I think the users should get a vote. And
that vote
should be cast with their decision to stay with 2.x, or switch to
3.x, or
try to support both. We should not muck with their rational
decision making
by putting "carrots" in one pile and abandoning the other.
The biggest issue to my mind is that adoption by the ultimate end
users is significantly hampered by the fact that big projects like
Twisted, numpy and the like, have no current plans to move to Python
3. Even end users with a reasonable level of coding expertise don't
have the time or resources to offer much in the way of help with a
port, when the project as a whole isn't interested in starting the
process.
For what it's worth, the official position of the Twisted project is
not that we have "no plan" to move to Python 3. It's that our plan is
to do exactly as Raymond suggests, and give the users a vote - in this
case, you vote with your patches :).
We are actively and frequently encouraging our users to contribute
patches that clean up warnings, which is the biggest impediment to a
py3 port of Twisted. Some of you would probably expecting to whinge
about how people never contribute anything, but actually, users *have*
shown up and started doing this. Our biggest problem at the moment is
that we don't have enough people doing code reviews so the
contributions are starting to pile up. As I said in my other message,
if someone would like to help, signing up to do code reviews would be
a good way.
Despite this progress, my hope is that there will be a robust 2.x
series up through 2.9.
For one thing, we have a very long row to hoe here. The migration to
3.0 is a long, tedious process with little tangible benefit. I hope
that sometime in the next decade Twisted can accelerate the process of
dropping old 2.x versions, but I seriously doubt we could do a feature-
complete 3.1/2.6 version. I get the general impression that a 3.2/2.7
port would be more feasible; hopefully a 3.3/2.8 would be even moreso.
Also, the benefits of migrating to python 3.x are still negligible, as
far as I can tell. On the one hand, you've got a Python with no old-
style classes and a clear unicode/bytes situation, and that's great.
On the other hand, you've got NumPy, PyGTK, Unladen Swallow, PyPy,
Jython, IronPython, and so on and so forth. Since I started using it,
the strength of Python has been in its ecosystem, and the 3.x
ecosystem is not yet viable.
As long as we're tossing out modest proposals here, I still think that
(as I believe James Knight already proposed) abandoning the current
3.x branch, backporting everything to 2.7, and continuing forward with
a migration strategy that introduces individual deprecations every
major version until 2.x == 3.x is the way to go. For example, 2.8
could emit a deprecation warning for every old-style class that was
defined, 2.9 could emit a deprecation warning for every string
constant declared without a 'b' or 'u' prefix unless the module in
question were in "3.x mode" (i.e. no-prefix == 'u'). (I leave the
determination of whether the parser should be in 3.x mode for a
particular module as an exercise for the reader, but a 'from
__future__' import would suffice.)
I realize that there are other issues here, like the C ABI changes
some NumPy folks have raised. Also, I'm not planning to actually do
any *work* on this suggestion, so you can take it for what it is,
which is to say, armchair quarterbacking.
There have been some other comments in this thread indicating that
this was not the case because some users indicated that they'd rather
deal with lots of changes "all at once". My understanding is that it
was done this way so that the *developers* of Python could make a
clean break, and design and implement a new version of Python without
being constrained by compatibility concerns. If you can show me an
actual application or library developer in Python who wanted this one-
big-jump migration, I will show you a crazy person.
The main reason I want a long 2.x series is that I believe it would
more easily allow us infrastructure folks to drop support for *older*
versions. With this big 2.x->3.x chasm, I can't really see an end in
sight for Twisted using Python 2.x as its _source_ language,
translating with 2to3. Some projects which depend on Twisted and want
new versions (and security fixes, etc) are going to want Python 2.x
for a really long time. Maybe they're just really conservative, maybe
they don't have a lot of maintenance energy, or maybe they have other
dependencies which haven't got a port; it doesn't really matter,
empirically speaking people want older versions of Python.
Keep in mind also that the 2.x translation process is extremely slow
and results in a clunky development process. There's no '2to3 --
interactive' commandline that lets me type python 2 at a >>> prompt
and get python 3 results out so that I can try experiments on the 3.x
interpreter; I have to actually put my experiments into my unit tests
and wait 10 minutes to see if it works. It's like writing C++.
With the 2.x series, users and operating systems seem to move on
fairly rapidly, because dependencies generally continue to work if you
upgrade just one version. This isn't quite as formal a requirement as
I would like (warnings get generated, unit tests fail, things do
break) but in practice, users can rely on it for most functionality.
If 3.x could be broken into a series of transitions like that, where
you can upgrade one version, fix some stuff, then upgrade another
version, even if you couldn't actually support more than 2 versions at
once, I think that we could pick up the migration pace to the point
where we might actually be using 3.x syntax in a few years. Having a
2.x series which goes to 2.9 and then stops isn't *quite* the same
thing as having one that moves over continuously to some 3.x version,
but it does seem to me that by that point the chasm between versions
will have narrowed to a crack, and the migration will be a little hop
over it rather than the currently-required great flying leap.
(To be fair, that leap is not the surface-to-orbit rocket-propelled
jump that I originally expected it to be. Still, it's still not a
small effort, especially if you're interfacing deeply with a lot of I/
O APIs.)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
