functional programming with map()

Andrae Muys amuys at shortech.com.au
Tue Feb 26 00:45:41 CET 2002


Paul Rubin <phr-n2002a at nightsong.com> wrote in message news:<7xbseeayxk.fsf at ruckus.brouhaha.com>...
> "Emile van Sebille" <emile at fenx.com> writes:
> 
> > "Paul Rubin" 
> > > Both of those build up a new list of the results, instead of
> > > discarding the values.  If the f function takes an integer and
> > > computes a 20-megabyte structure, you've got a problem.  
> > 
> > If you know it's coming, throw it away first:
> > 
> > [x.f() and None for x in items]
> 
> OK, but that buidls a list of None as long as the item list.  Not
> so bad, since it gets reclaimed right away, but still unsatisfying.
> 
> > filter(None,[x.f() and None for x in items])
> > 
> > returns an empty list vs 0 for the reduce.  
> 
> Again there's this intermediate list that's as long as the original list.
> 
> Do you see a way around that?
> 

filter(lambda x:x.f() and 0, items) ?

It's identical to the the reduce method posted previously, but avoids
the tuple indexing required by reduce's use of a binary operator vs.
filter's unary.

Of course my first preference would be the list comprehension,
discarding the redundant list, and if that was prohibitively expensive
falling back to the original imperative style.

Andrae Muys



More information about the Python-list mailing list