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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4