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.
> 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.
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.
Over the years, people have written on c.l.p about 'lambdas' as if they
were a separate class of objects somehow different from def objects (and
not just an expression). I believe writing and reading both 'name =
lambda ...' and 'def name(...' engenders and reinforces this delusion,
especially for beginners.
Admittedly, the lack of a func_name attribute can sometimes make
tracebacks harder to understand, especially if you've got many bound
lambdas.
Is saving two keystrokes worth that disadvantage, and the confusions
mentioned above? To me, no. Hence my advice.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list