[Python-Dev] [Python-3000] Warning for 2.6 and greater

James Y Knight foom at fuhm.net
Thu Jan 11 20:09:42 CET 2007


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.



More information about the Python-Dev mailing list