On Jan 10, 2007, at 6:46 PM, Benji York wrote:
> Paul Moore wrote:
>> How many other projects/packages anticipate *not* migrating to
>> Py3K, I wonder?
>
> I certainly can't speak for the project as a whole, but I anticipate a
> fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0.
I (another Twisted developer, among other hats I wear) am also very
worried about the Python 3.0 transition.
If the goal is really to have Py 3.0 be released later this year,
Twisted will almost certainly want to still be compatible with Python
2.4 at that time. (Note that it's currently compatible down to Py
2.3). Even discounting that level of compatibility, it's gonna have
to be _at least_ compatible with whatever the latest 2.X release is
(2.5, I guess, is the plan?).
Due to a lack of manpower, it is also not in all probability a
realistic option to maintain two parallel almost-identical
development branches, one that supports Python 2.x and one that
supports Python 3 [1]. It would be quite a shame if this meant that
Twisted effectively cannot move to Python 3.x for years after its
release. I don't think anyone wants to see this happen. (and when I
say "Twisted" here, I really mean "*every* sizeable python module or
program with any current user base whatsoever".)
If Python 3.0 was simply a release which removed deprecated features,
there would clearly be no issue. I would update my code in advance of
the 3.0 release to not use any of those features being removed, and
I'm all set. But that's not what I'm hearing. Python 3 is both adding
new ways to do things, and removing the older way, in the same
version, with no overlap. This makes me very anxious.
Basically: my plea is: please don't remove the old way of doing
things in Py 3.0 at the same time as you add the new way of doing
things. Have a couple versions of compatibility, just for me (and the
other thousands of people in the same situation). Please do make the
language better, and please do remove huge swaths of old deprecated
APIs and functionality. Just, please don't gratuitously remove an old
API to make Python a tiny bit cleaner, when there's not already
something I can reasonably do *today* to replace it.
The dict.keys() change is a simple illustrative case.
Here's the situation as I understand it:
In Python 2.X, if I want an iterator of items, I call d.iteritems().
d.items() returns a list.
In Python 3.X, if I want a iterator (or maybe an set-view; doesn't
matter to me) of items, I call d.items(). There is no d.iteritems()
I'm completely positive about the change to make d.items() not return
a list. It's a great thing to do. But note that there is NOTHING [2]
I can call in order to get an iterator of items on both versions! If
I want my code to work properly on both, I'll have to write a wrapper
function that depends on the python version, like:
if py3k:
def dict_iteritems(d):
return d.items()
else:
def dict_iteritems(d):
return d.iteritems()
Clearly this is one of the simplest possible wrappers to write, but
It's going to make code really ugly to have to use wrapper functions
everywhere instead of methods. My point: is it *truly* necessary to
completely remove .iteritems() in the same release that .items() gets
iterator behavior? It would make every 3rd party developers' life so
much easier if iteritems() stuck around a for another few releases
after 3.X gains traction, and I really can't see any downside.
Of course, this is only one simple example, and if this was the
_only_ incompatible change in Py3k, it would be non-ideal, but not a
huge problem. But this same point goes for every single change. All
the bidirectionally-incompatible changes put together may very well
turn into one huge problem.
James
[1] Unless of course there's a perfect automated conversion script
that can generate the 3.X compatible source code from the 2.X
compatible source code. But since such a script is basically
impossible, I doubt that's going to be the case. Feel free to prove
me wrong here, of course. (but if it is possible, simply build it
into python 3.0 so that it can convert old modules at load time and
make everyone happy!)
[2] iter(d.items()) _does not count_. That is unacceptable on Python
2.X due to the overhead of making the huge list.
_______________________________________________
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
