I sing the praises of lambda, my friend and savior!

[Bengt Richter]

On Mon, 11 Oct 2004 12:36:21 -0400, "Clark C. Evans" <cce at clarkevans.com> wrote:

>What? is lambda is going away?  Say it ain't so!
>
>On Fri, Sep 17, 2004 at 08:26:19AM +0000, Bengt Richter wrote:
I didn't write the following, I replied to it. Note the extra quoting level.
You are quoting Steven Bethard. See
http://groups.google.com/groups?hl=en&lr=&selm=mailman.3440.1095407177.5135.python-list%40python.org
 ;-)

>| >f = lambda args: body
>| >   is equivalent to
>| >def f(args): body
>
It really should be
    f = lambda args: expr
is equivalent to
    def f(args): return expr
except for little details like f.__name__ and perhaps vestigial unexecuted
byte code in the def version, until someone thinks it's worth the bother to optimize out.

>Not really -- the item above is _bad style_, people write,
>
>  def f(args):
>      body
>
>|    obj.f = lambda args: body
>
>Or more commonly,
commonly compared to what? obj.f = ... ?
>
>  func(arg, lambda args: body)
>
>| I'd rather use lambda.
That line I wrote, though the context is snipped ;-)

>
>No joke.  For the common case above, which occurs _everywhere_ 
>in my 'deferred execution' code, one would write:
>
>   def somerandomname(args):
>       body
>   func(arg, somerandomname)
>
>So, you've taken something that is a perfectly clear one-liner and
>converted it into a 3 line chunk of code with _zero_ added clarity,
>in fact, I'd say you've dramatically reduced clarity by requiring
>the a name be 'minted'.  Ugly.  Multiply this by 10x in one of my
>source files and you've taken something perfectly readable and
>turned it into maze of confusion.  This _hides_ the true intent
>rather than making it clear that the function is temporary thingy.
>
[Not Bengt]
>| >Not that it's coming any time soon, but Python 3000 is supposed to remove 
>| >lambda functions
>
>Expect me to whine very loudly on a daily basis when Python 3000 
>becomes near.  In fact, let the preemptive supplication begin.
>
[Bengt]
>| Well, if lambda is removed (or not ;-), I hope an anonymous def 
>| expression is allowed, so we can write
>| 
>|    obj.f = def(args):
>|                body
>| or
>| 
>|    obj.f = def(args): body
>| 
>| or
>| 
>|    obj.f = (
>|        def(args):
>|            body
>|    ) 
>
>Ewww.  How is this better than lambda? Let's keep lambda, no?
>
Sure, lambda is fine, but it doesn't allow statements, so something
like def is needed. Just dropping the def name and allowing the
def statement to be an expression seemed an easy step, since the
name is basically the only difference.

As seen above, finding an indentation style that is easy to read is
a challeng, especially if the anonymous def is a middle argument to
a functions call, e.g.,

    func(arg1, (def(x): print x), arg3)

much as with lambda, you may need parentheses to show where the expression ends.
For a more complex def, we get into multiple lines in the arg list, e.g.,
expanded,

    func(
        arg1,   # use a new line to get consistent indenting of arg list items
        (def(x, base=10):
            """even anonymous defs could have doc strings"""
            return int(x+'0', base) # weird function
        ),
        arg3
    )

or, more compactly,

    func(arg1,
         def(x, base=10):
             """even anonymous defs could have doc strings"""
              return int(x+'0', base) # weird function
         ,arg3)

It's a tough style problem. But what would you do with lambda, given that
we don't have lots of insignificant silly parentheses?

Regards,
Bengt Richter