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