[Python-iterators] While we're at it...

[Tim Peters]

[Tim, quoting from eventual 2.2 NEWS]
> - The following functions were generalized to work nicely with iterator
>   arguments:
>     map(), filter(), reduce(), zip()
>     [many others omitted]

[David Eppstein]
> Is there a PEP for this?  It doesn't seem to be in 234.

Right -- as Thomas said, it's "too obvious".  All the contexts mentioned
worked by iterating over sequences before, and the Iterator PEP generalized
the notion of iterating over sequences.  So it was just screamingly natural
to generalize *all* contexts that iterated over sequences in the same way.

> Can I assume that "work nicely" means they act like simple generators
> in yielding partial results even when their inputs are infinite
> sequences?

No, and *none* of them do except for those that did before; for example, zip
stops as soon as any of its sequence arguments says "I'm done", even if
other zip arguments have not been exhausted:

>>> zip(range(3), xrange(sys.maxint))
[(0, 0), (1, 1), (2, 2)]
>>>

These have always returned (for the most part) lists, and that can't be
changed:  lists have a rich set of methods, while iterators have only one
("get me the next item"), so we can never change a list-producing context
into an iterator-producing one without risking major code breakage.

That's OK by me!  While I've been spending some of my work time and
virtually all of my "spare time" getting this new stuff to work well, it's
not something I expect people will use *routinely*.  Explicit lists are
great, and mucking around with lazy alternatives is something most people
won't have to worry about most of the time.  When you do need to worry about
it, the new facilities are great too, but you'll have to "do something" to
get them then.  For everyone else, it's 100% backward compatible (even
better, faster than it was before, and easier to write new iterators).