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

Reply via email to