>> * imap() - It's not clear to me why it differs from map() other than
>> the fact that it's an iterator.
Raymond> The other differences are that it stops with the shortest
Raymond> iterable and doesn't accept None for a func argument.
I understand that. I was questioning why with a name like "imap" you chose
to make it differ from map() in ways other than its iterator-ness. The
other semantic differences make it more difficult to replace map() with
itertools.imap() than it might be.
Raymond> Because one or more useful inputs are potentially infinite,
Raymond> filling in Nones is less useful than stopping with the shortest
Raymond> iterator.
Yes, but it still seems a gratuitous change from map() to me.
>> * loopzip() - It's not clear why its next() method should return a
>> list instead of a tuple (again, a seemingly needless distiction
>> with its builtin counterpart, zip()).
Raymond> I've wrestled with the one. The short answer is that zip()
Raymond> already does a pretty good job and that the only use for
Raymond> loopzip() is super high speed looping. To that end, reusing a
Raymond> single list instead of allocating and building tuples is *much*
Raymond> faster.
How do you know the caller doesn't squirrel away the list you returned on
the n-th iteration? I don't see how you can safely reuse the same list.
Skip
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