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

[Jeff Shannon]

gabriele renzi wrote:

>
> 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.


But because of Python's line- and indentation-based syntax, doing all of 
that on a single line is... um... awkward at best, to put it mildly.  
And once you make a lambda multiline, then you lose most of the point of 
it -- at least, as far as I understand what the point is (having an 
in-line, anonymous callable).  Once you allow statements and multiple 
expressions, all you're gaining is anonymity, which seems like a pretty 
paltry benefit to me.

>> 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.


I agree that, if a case is *very* useful, it is possible to break the 
rules.  List comprehensions, for example, break some of the rules, but 
they are indeed very useful, so the rule-breakage is more forgiveable.

Maybe I'm just ignorant or behind the times, but I still haven't seen a 
real argument as to *why* lambdas are so useful.  There's some 
assertions about how avoiding giving something a name makes things 
clearer, which I disagree with.  ('Explicit is better than implicit.'  I 
don't see how 'no name' makes the purpose of a code segment clearer than 
'some meaningfully descriptive name', no matter how many times it's 
asserted.)  There's complaints that it takes a whole two extra lines to 
type a proper function def, as opposed to being able to use lambdas 
inline... but again, I'd claim that with a properly named function, the 
intent at point-of-use will be quite clear and the cost of two extra 
lines of code is minimal.  (I also tend to break complex expressions 
into multiple steps to increase clarity -- packing as much as possible 
into a single line doesn't strike me as all that desirable.)  There's 
complaints about polluting the namespace... but ISTM that it's not 
*that* hard to come up with uniquely descriptive names.  Lambdas may 
once have had some utility in capturing and tinkering with the scoping 
of names, but that became moot with the introduction of nested scopes 
'way back when.

I understand that lambdas are very popular in other programming 
languages (such as Lisp).  But Python is not those languages, and which 
constructs are useful may well be different.  I don't know enough Lisp 
to judge how helpful lambdas are there; I do know enough Python to 
believe that I should be able to see the advantages if they were as 
wonderful as their proponents say.  My suspicion is that all of the 
Python users who like lambdas originally discovered them in other 
languages and are comfortable with them from that environment, but those 
who have no previous exposure to lambdas tend to be unimpressed (at 
best) by Python's take on them.  This renders them, IMO, in the same 
category as the ternary operator that's continually proposed by converts 
from, say, C/C++ -- a feature whose usability is much greater in other 
languages than in Python, and whose inclusion would only satisfy those 
familiar with the feature from those other languages.  The only 
difference between the two features, IMO, is that someone managed to 
talk Guido into including lambdas (which he reportedly regrets), and 
nobody managed to talk him into including the ternary operator.

Jeff Shannon
Technician/Programmer
Credit International