[Python-Dev] [Python-3000] Warning for 2.6 and greater (original) (raw)
Scott Dial scott+python-dev at scottdial.com
Wed Jan 17 00:42:35 CET 2007
- Previous message: [Python-Dev] [Python-3000] Warning for 2.6 and greater
- Next message: [Python-Dev] buglet in long("123\0", 10)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin v. Löwis wrote:
It would still "suffer" from the cross-module issue:
# a.py from future import itemsisiterator 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
- Previous message: [Python-Dev] [Python-3000] Warning for 2.6 and greater
- Next message: [Python-Dev] buglet in long("123\0", 10)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]