Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sun, 24 Feb 2008 21:13:08 -0500, Terry Reedy wrote:
>
>> | I even use "named anonymous functions" *cough* by assigning lambda
|
>> functions to names:
>> |
>> | foo = lambda x: x+1
>>
>> Even though I consider the above to be clearly inferior to
>>
>> def foo(x): return x+1
>>
>> since the latter names the function 'foo' instead of the generic
>> '<lambda>'.
>
> Absolutely. If foo() was a function that the user would see, I would
> certainly use the def form to create it.
>
> But in a situation like this:
>
>
> def parrot(x, y, z, func=None):
> if func is None:
> func = lambda x: x+1
> return func(x+y+z)
>
>
> I don't see any advantage to writing it as:
>
> def parrot(x, y, z, func=None):
> if func is None:
> def func(x): return x+1
> return func(x+y+z)
>
>
>
I take it you never feel the need to inspect tracebacks, nor insert a
breakpoint or print statement at an arbitrary point in the code.
Granted none of those may apply in this particular simple case, but if
you pass functions/lambdas around a lot it can be frustrating when you
get an error such as:
TypeError: <lambda>() takes exactly 2 arguments (1 given)
and the traceback only tells you which line generated the TypeError, not
which lambda was involved. On the other hand:
TypeError: parrot_func() takes exactly 2 arguments (1 given)
while it might not identify the function uniquely in all situations at
least tells you something useful about the function being called.
--
http://mail.python.org/mailman/listinfo/python-list
