Let's Talk About Lambda Functions!

Alex Martelli aleax at aleax.it
Sat Jul 27 16:25:18 EDT 2002


Carl Banks wrote:
        ...
>>>     def sort_the_right_way (f, a):
        ...
> Come on!  Wrapping up a sort in a function is an "ambitious
> framework"?  I'm talking about writing a single function because a
> certain sort appears a dozen or so times in the code.  I'm sure you're
> aware of the advantages of putting oft-repeated code into one place.

If the SAME sort appears repeatedly, it surely needs to be a
function.  But you do have to get your parameters right when
"same" is not exactly "same".  And if it gets to...:
        ...
>>>     sort_the_right_way (lambda x:x[1], a)

...the lambda suggests imperfect factorization.  If this "same" sort
does occur often, IS it the case that this is the ONLY place where it 
needs to be by the 1-th item?  Or, by AN item?

Statistically, it IS possible that the sort is both frequent enough
to deserve factoring out AND yet so varied and diverse in the criteria
to use that a general function is the only effective way to express
them AND that this one in particular is a freak case never to reoccur,
so that naming the sortfield-selector function (while not a problem)
MIGHT be fractionally suboptimal.

The combination of each of these unlikely factors, all together,
multiplies down to a VERY small chance.  And naming the sort selector
function is such a TINY "cost" to pay (come on, now, HOW horrible is
it to have to name even such a function as the above one?), even in
the extremely unlikely case that it IS a cost at all (rather than,
as far more likely, a benefit), that *lambda is not pulling its own
weight in the language*.  It cannot, hobbled as it is: it's a wart,
deadweight, better forgotten.


>> Somebody ambitious enough to encapsulate DSU should surely proceed
        ...
> So now you're advocating building a framework of closures to replace

No, I'm saying that IF somebody was ambitious enough to encapsulate
DSU, then the same somebody should be consistent and proceed along
the same route.  "If the fool would persist in his folly he would 
become wise" (Blake).  Can't you read?

> hated lambdas, I would just write:
> 
>     def second(x): return x[1]

If that's what you need, fine.

> (Of course, I'll write the closure if the need ever comes to have the
> program select the index.)
> 
> What I'm saying is, your objection that this use of lambda only is
> necessary because of over- and under-generalizatino isn't true for my
> circumstances.

I don't know you well enough to use my judgment about your specific,
individual circumstances, but I *DO* know that I *NEVER* said, implied,
inferred or let it be suspected that "this use of lambda is
*NECESSARY*" (my emphasis).  It obviously *ISN'T* _necessary_, as
your hypothetical function "second" shows.  You DO know what
"necessary" means, yes?  It's a MUCH stronger word than, say,
"opportune".  What an extremely unlikely combination of circumstances
MIGHT cause (and I cannot rule out that your personal, individual
circumstances might be exactly those), are cases in which lambda
is *vaguely defensible* -- never necessary, but if every single one
of those circumstances (and more yet, such as, no need ever to stray
from the confines of what can comfortably be put in an expression)
obtained, then using lambda wouldn't be totally absurd.

It still would be INFERIOR (e.g., debugging would be harder as
the traceback would not identify the failing extractor by name,
as 'second', but only anonymously as 'lambda' -- who lives by
the sword [of anonymity]...), but not absurdly so.

But it's far simpler to never use lambda, than to analyze each
case to ascertain whether it's absurd or merely inferior to use
it in any single given case.  Great saving of energy, to have
one less "way to do it" when that "way" is such a loser.


> Personally, I don't care about saving lines, per se.  For me, lambda
> helps me to avoid stopping mid-function call, scrolling many or few
> lines to implement the function as a def, and returning.  I.e.,
> lambdas save me cursor movement.

In VIM, I hit ESC, uppercase-O, and I'm in insert mode on a newly
inserted immediately-previous line with correct indent, ready to
flow on with def and so on.  I assume more powerful editors and
IDEs, such as EMACS and the like, must have facilities at least as
powerful.  Thus, the "saving" seems utterly trivial.


Alex




More information about the Python-list mailing list