[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!