[Python-3000] map() Returns Iterator

[Calvin Spealman]

I can't remember specifics, but i had always expected map and filter
to be replaced by their itertools counter parts.

On 8/4/07, Kurt B. Kaiser <kbk at shore.net> wrote:
> 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
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/ironfroggy%40gmail.com
>


-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/