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

Scott Dial scott+python-dev at scottdial.com
Wed Jan 17 00:42:35 CET 2007


Martin v. Löwis wrote:
> It would still "suffer" from the cross-module issue:
> 
> # a.py
> from __future__ import items_is_iterator
> def f(d):
>   return d.items
> # b.py
> import a
> d = {}
> print a.f(d)
> 
> For compatibility with 2.x, a.f should really return a bound
> method that returns lists; for compatibility with 3.x, it will return
> a method that produces an iterator.
> 
> Of course, one might say "don't do that, then".
> 

This seems like a perfectly reasonable thing to say. If I am writing 
something for 2.X and want to use a 3.X feature switch, then I am 
responsible for maintaining the external API, be it the 2.X version of 
d.items if that is what is expected by the user.

Your complaint only works if a.f was pre-defined to return a list, which 
the developer of "a" would know about when he decided to flip on 
items_is_iterator. As a part of that refactoring, he would patch up the 
return to be list(d.items) to maintain the API he has already defined. 
It is not clear by your example that "b" wasn't in fact expecting to get 
an iterator, which is now a great deal simpler thanks to the future 
statement.

My point is simply that this argument doesn't work unless you assume the 
developer of "a" has failed to do his job (which is to maintain the 
external API by also testing the external API).

BTW, I patched your code because both versions you have presented didn't 
actually work.

-- 
Scott Dial
scott at scottdial.com
scodial at cs.indiana.edu


More information about the Python-Dev mailing list