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 <[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/ironfroggy%40gmail.com > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ _______________________________________________ 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
