[Python-3000] map() Returns Iterator

[Jeffrey Yasskin]

<wild-speculation>
Is it possible to make the result of map() look like a list if people
are paying attention, but use memory like an iterator when they're
not? We'd want to distinguish between:
  x = map(...)
and
  for x in map(...)

Actually, to get any use out of it, we'd need to allow the first case,
as long as the first call to .__iter__() were also the last use of the
value. (I think this makes the return value of map() a 'view' rather
than an iterator?) How could we know that in time to do something
about it?

It looks to me that this could be accomplished if the last use of a
variable in a particular scope didn't increment the reference count
when passing that variable to a function. (Of course, I don't know
anything about how function calls actually work, which is why this is
wild speculation.) Then when the map-view's .__iter__() method is
called, it could check self's reference count. If that count is 1,
just proceed to iterate down the list, throwing away values after
computing them. If the count is >1, then create a list and fill it
while computing the map.

This could also be a handy optimization for plain list iterators, and
maybe other types. If .__iter__() is called on the last reference to a
particular value, then as it walks the list, it can decrement the
reference count of the items it has passed, since nobody can ever
again retrieve them through that list.
</wild-speculation>

Also, calling map() for its side-effects is a perversion of the
concept and shouldn't be encouraged by the language. Write a for loop.
;)

On 8/3/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/jyasskin%40gmail.com
>


-- 
Namasté,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

"Religion is an improper response to the Divine." — "Skinny Legs and
All", by Tom Robbins