<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 <[EMAIL PROTECTED]> 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@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 _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
