Éric Araujo <mer...@netwok.org> added the comment: Peter’s patch now uses iter(thing) instead of len(thing) to assess sequenciness. I made this comment: > You can iterate over an iterator (which is not a sequence). Here I > don’t know if the code talks about sequence because it pre-dates > iterators or because it really wants sequences.
Peter’s reply: > Fair point. The *code*, though, doesn't say either, and len() doesn't > express it any better (IMO) than iter(). It seems to me that the > check basically just verifies that the presumed sequence can be > safely iterated over, before trying to enter the for loop. If so, my > iter() check seems to encapsulate it cleanly in code rather than > needing an additional comment. I think iter may exhaust a non-repeatable iterable, whereas len would give a TypeError and not consume the iterable. iter(thing) being successful does not guarantee that a second iteration will succeed. I’ve had a look at the docstring and the reST docs, and they clearly say that sequences are supported, not arbitrary iterables. > If not -- if the code should enforce "true sequence-ness" -- maybe it > should use the ABC (as my first patch did)? Which is *correct*, > though, I'm too much an outsider to judge! Note that ABCs are not strict, “true” type checks like there is in other languages :) > (I tried to check the revlog for clues, but the code entered in > 5a416a6417d3, which was the new urllib package combining several old > packages. It's been there for a while.) Log viewing tools usually let you follow the history across renames, or otherwise let you see the history for a file that’s not anymore in the tip revision. Here it was Lib/urlparse.py. (Just saying this for your information, it does not matter anymore to check the history to find if the code pre-dates iterators.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12581> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
