I sing the praises of lambda, my friend and savior!
rff_rff at remove-yahoo.it
Mon Oct 11 21:20:45 CEST 2004
Jeff Shannon ha scritto:
Let me say that all of this is in a big IMO block. Oh, and sorry for the
triple post, thunderbird got mad.
> Except that one of the design principles of Python is that it being easy
> to *read* is more important than being easy to write, with the
> assumption that much of the code that one reads will be code written by
> someone else. I do care how readable your code is, because (at least in
> principle) someday I may need to maintain it. ("If you don't like X,
> don't use it, but let others use it if they like" seems to be much more
> Perlish than Pythonic, at least IMHO.)
I agree on the perlish thinking of 'some more feature you can avoid are
good'. But lambdas are a concept that can be (and actually is) used for
a lot of things where it is better than others.
> Lambdas are hard to read, because they're significantly different,
> syntactically, from any other construct in the language -- it's not that
> I'm _unwilling_ to learn, it's that it is actively *difficult* to learn
> because it doesn't fit well, conceptually, into the rest of the
> language, so there's a mental impedance barrier that must be overcome.
IMO the problem is just that lambda is an onion (citing paul graham that
cites primo levi google for the explanation). It is a remnant of
academic computer science.
Would you like to have it like:
func arg1,arg2: arg1+arg2
Again, IMO the point is: once people explain this to you, would you find
hard it to understand or read a lambda once you find them again?
Is this different from the strangeness of array literals or generator
> In order to explain lambdas to someone who is not already familiar with
> them, you have to explain first that it's kind of like a function def,
> except that it uses totally different syntax (aren't function defs
> supposed to use parens?), and you don't explicitly return anything even
> though it *does* return a value, and oh yes, you can't actually use
> statements because it has to be a single expression (and then you get to
> explain the difference between statements and expressions, and explain
> *why* there's a difference and that it really is a good thing)...
then what you want is a better lambda. One where you can use return,
maybe, and where you can have statements and multiple expressions.
Don't throw away the baby with the bathwater.
> That's a lot of special treatment for those cases where there actually
> might be a slight advantage to using an anonymous function, and "Special
> cases aren't special enough to break the rules." Lambdas *do* break
> many of Python's usual rules.
Just because you're thinking of lambdas as special cases. Whenever a
case is very useful it is possible to break the rules. That's why there
are all those funny literals.
More information about the Python-list