[Python-3000] map() Returns Iterator

Sun Aug 5 15:20:33 CEST 2007

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/