[Tutor] Problems with genetically engineering the Print Ogre

Danny Yoo dyoo@hkn.eecs.berkeley.edu
Fri, 1 Mar 2002 11:53:13 -0800 (PST)


On Fri, 1 Mar 2002, Jeff Shannon wrote:

> *looong* time ago), but.... While I can see the point, that
> 
> [x for x in ... ]
> 
> is a little bit odd looking, the moment that you throw some other
> operation in x (i.e., you're doing anything other than a pure filter),
> list comps seem *much* clearer to me.
> 
> [f(x) for x in mylist if x > 10]
> 
> vs.
> 
> map(lambda x: f(x), filter( lambda x: x > 10, mylist))

I think this is being a little unfair to map() and filter().  *grin*


The first lambda part is redundant, because we can just pass 'f' directly
to map.  That is, instead of saying:

    "Call map with an-anonymous-function-that-calls-f(x)",

it's easier to say:

    "Call map with function f":

###
map(f, filter(lambda x: x>10, mylist))
###


If we'd like, we can also yank that second lambda outside as a separate
function:

###
def is_greater_than_ten(x):
    return x > 10

map(f, filter(is_greater_than_ten, mylist))
###


I guess I'm trying to say that map() and filter() don't have to look
weird.  *grin* Good luck!