On Sat, 12 Jul 2008 16:32:25 -0400, Terry Reedy wrote:
> Steven D'Aprano wrote:
>> On Thu, 10 Jul 2008 14:09:16 -0400, Terry Reedy wrote:
>>
>>>>>>>> g = lambda x:validate(x)
>>> This is doubly diseased.
>>>
>>> First, never write a 'name = lambda...' statement since it is
>>> equivalent to a def statement except that the resulting function
>>> object lacks a proper .funcname attribute.
>>
>> Using lambda in this way is no more "diseased" than aliasing any other
>> object.
>
> In the context of giving advice to a confused beginner, I disagree. He
> must learn def statements. Lambda expressions are optional.
Lots of things are optional. sets and frozen sets and decorators and
classes and all sorts of things are optional, *and* capable of being
misused and/or abused. Would you describe properties as "diseased"
because some people might fill their classes with useless getters and
setters?
> > It's a matter of personal preference not to bind a lambda to a
>> name. Functions, whether created by lambda or def, are first class
>> objects, and as such there's nothing wrong with binding them to names.
>
> When I brought this up on pydev, in the context of a style guide
> addition, about 9 of 10 respondants agreed that this should be
> discouraged. Alex Martelli reported his experience that this
> construction more often leads people to the useless wrapping of function
> calls, such as the OP posted, than the def statement equivalent does.
I have great respect for Alex, but anecdotes of that nature aren't proof.
Such anecdotal evidence is subject to confirmation bias. I'm sure that
Alex remembers the stupid pieces of code where people make such mistakes
but I doubt very much he remembers the cases where they don't.
But as a style guide... fine. Tell people it is discouraged. Tell them
that other Python developers will laugh at them if they do it, apart from
the ten percent who don't mind named lambdas. Point out that, like
factory functions, there's a debugging cost to having functions with a
unhelpful func_name attribute.
But don't cross that line from discouragement to telling people that it
is wrong to use named lambdas. That's what I object to.
> One of the major reasons people give for wanting lambda expressions kept
> in Python and for using them is that they do not want to have to think
> up a name for short expressions. If such a person then turns around and
> binds the resulting function object to a name, then that rationale
> disappears.
That does not follow. The fact that I might choose to occasionally bind a
lambda to a name doesn't mean I never use unbound functions. Your
argument is like saying that the rationale for air conditioners ("cooling
in the hot weather") disappears because we can also use reverse-cycle air
conditioners for heating in the cold weather.
Lambdas are *necessary* if you want anonymous functions, just as we have
anonymous strings, anonymous integers and so forth. It would be a poor
language that forced people to write this:
x = 1
s = 'two'
def f(arg):
return arg+3
mylist = [x, s, f]
instead of the more sensible:
mylist = [1, 'two', lambda arg: arg+3]
That's why we need lambda. But once we have lambda, there is absolutely
no reason why we must prohibit other uses of it. Given the above
definition of mylist, would you then describe the following piece of code
as "diseased"?
def foo(mylist):
g = mylist[2]
for i in xrange(10000):
print g(i)
That's a perfectly good micro-optimization technique, and I would hope
you would not reject it merely because the function was anonymous. That
would be irrational.
I'm not defending the Original Poster's use of lambda in that specific
piece of code. You are right to criticize it *specifically*. What I
object to is that you generalize that criticism, and treat a personal
preference as an absolute rule. By all means think my code is ugly for
using named lambdas, and by all means tell me you think it is ugly, but
don't tell me I'm corrupting the youth of today with my filthy disease-
ridden code.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
