>> * 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