homepage

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.)