Let's Talk About Lambda Functions!

[Carl Banks]

Alex Martelli wrote:
> Carl Banks wrote:
>> Second, if you're going to do it right often, you might want to wrap
>> it up in a function like this:
>> 
>>     def sort_the_right_way (f, a):
>>         aux = [ (f(x), x) for x in a ]
>>         aux.sort()
>>         a[:] = [ x for __, x in aux ]
> 
> You can do that, but then you risk 'freezing' in your higher order
> function a suboptimal way to proceed -- e.g., no way this function
> can be told to produce stable sorts, while keeping DSU inline it's
> trivial to ensure the sort is stable.
> 
> The temptation to overgeneralize often accompanies the decision to
> freeze some idiom into a higher-order function.  Keeping the idiom
> inline avoids temptations to overgeneralize.  Thus, while it does
> fly in the face of accepted wisdom, in Python sometimes it's wiser
> to NOT refactor too many idioms and design patterns into ambitious
> frameworks.

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 you need another kind of sort for some reason, just don't use the
function.


[snip]
> 
>> In which case, the temptation to use lambda returns:
>> 
>>     sort_the_right_way (lambda x:x[1], a)
> 
> Somebody ambitious enough to encapsulate DSU should surely proceed
> by encapsulating typical accessors to be used with it in closure
> factories, e.g.
> 
>        sort_the_right_way(make_items_acessor((1,)), a)
> 
> thereby avoiding lambda again.  It's only when stuff gets wrapped
> at once too much (by freezing some subset of DSU into a higher
> order function) AND not enough (by not supplying other higher
> order functions to go with it by building needed closures) that
> the _temptation_ of lambda'ing around perks up.  Easily avoided
> by noting that even in that case one more def does it, of course.

So now you're advocating building a framework of closures to replace
the lambdas?  This is what appears odd to me: you want me to inline
sorts in the interest of not overgeneralizing, but it seems the same
can be said by your use of make_items_accessor above.

I have good reasons for my choice of where I generalize.  I've never
needed to be particular about the order of equal items; indeterminate
is fine for me.  One way to sort has sufficed for my whole life, thus,
it makes sense for me to generalize.  OTOH, I rarely have a use for
generalizing x[1], so I would not bother with a closure.  Even if I
hated lambdas, I would just write:

    def second(x): return x[1]

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


> It takes one more line -- saving lines is probably the core
> fetish of lambda-enthusiasts, after all.  I propose again the
> hypothesis that such obsession may be linked to traumas in
> one's childhood...

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.


-- 
CARL BANKS
http://www.aerojockey.com