[Python-3000] map() Returns Iterator

[Kurt B. Kaiser]

Although there has been quite a bit of discussion on dropping reduce()
and retaining map(), filter(), and zip(), there has been less discussion
(at least that I can find) on changing them to return iterators instead
of lists.

I think of map() and filter() as sequence transformers.  To me, it's
an unexpected semantic change that the result is no longer a list.

In existing Lib/ code, it's twice as likely that the result of map()
will be assigned than to use it as an iterator in a flow control
statement.

If the statistics on the usage of map() stay the same, 2/3 of the time
the current implementation will require code like

        foo = list(map(fcn, bar)).

map() and filter() were retained primarily because they can produce
more compact and readable code when used correctly.  Adding list() most
of the time seems to diminish this benefit, especially when combined with
a lambda as the first arg.

There are a number of instances where map() is called for its side
effect, e.g.

        map(print, line_sequence)

with the return result ignored.  In py3k this has caused many silent
failures.  We've been weeding these out, and there are only a couple
left, but there are no doubt many more in 3rd party code.

The situation with filter() is similar, though it's not used purely
for side effects.  zip() is infrequently used.  However, IMO for
consistency they should all act the same way.

I've seen GvR slides suggesting replacing map() et. al. with list
comprehensions, but never with generator expressions.

PEP 3100: "Make built-ins return an iterator where appropriate
(e.g. range(), zip(), map(), filter(), etc.)"

It makes sense for range() to return an iterator.  I have my doubts on
map(), filter(), and zip().  Having them return iterators seems to
be a premature optimization.  Could something be done in the ast phase
of compilation instead?






-- 
KBK