I sing the praises of lambda, my friend and savior!
jeff at ccvcorp.com
Mon Oct 11 22:51:00 CEST 2004
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.
More information about the Python-list