I sing the praises of lambda, my friend and savior!

gabriele renzi 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 
expression/LC ?

> 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 mailing list