First of all, your objection to anonymous functions with an example that names the function in two different places kind of takes us off topic from the discussion of "anonymous" functions, but I will still respond.

Second of all, multiline-lambdas are already possible in Python, but they are not anonymous functions.

Anonymous functions, as I said, allow for rich syntax; they do not affect the Turing completeness of the language. The context I am speaking of is "expressibility" in the sense of natural language, not whether or not something is expressible at all.

Ruby allows you to do stuff like this fairly naturally:

def process_event_until_timer_expires # check time, then call block only if # timer not expired end

process_events_until_timer_expires { |t, event| puts t fire_event_downstream(event) }

Having an anonymous function here allows you to read from outside in, which is more natural. From the outside, you know you are in some event loop, then you can look inside the block to see the details of how the event are handled. It's really that simple. Not earth-shattering different than Python, just subtly different and more expressive.

I've been using Python for a decade, and Ruby's still overly exotic to me, so I am sympathetic to people that defend the more Pythonic approach. But Ruby does allow for a different kind of expressiveness here.

Javascript also makes heavy use of anonymous functions, and if you use anonymous functions in other languages, you realize that they have value, even if they are occasionally abused and technically unnecessary.

The real problem with lambdas in Python isn't that they're restricted to one expression, but that Python's implementation of closures is clumsy (due to a scoping ambiguity). The argument about whether lambdas should be named or not is a canard. In languages that make heavy use of lexically scoped functions defined on the fly (Scheme, ML, etc.), they're often given local names. The problem is that Python's locally defined functions are less expressive. Apparently making heavy use of closures is not "pythonic".

You are correct. There is no reason not to just use an inline function that happens to have a name. I think the "lambdas can only be one line" is a newbie python mistake.

Personally, I dislike naming things that I won't use again. It feels like a waste. And then, since I have to name things, I have to come up with a _good_ name.

Just a matter of taste, mind you, but it's my reasoning for preferring anonymous functions.

They do make code more readable sometimes... but I think they are often used in Ruby as an alternative to @obj.method(:foo) -- in other words the Rubyist would use lambda{@obj.foo} and the pythonista would use obj.foo

> Lambdas are for "one-liners", functions are for more-liners.

The problem, though, is that this is entirely a Python conceit. It is in no way, shape, or form any kind of programming truism. In fact, taking a more principles-oriented approach, a named function is really just a special case of a lambda. I think this may be one of those things that using a LISP (such as Scheme or Common Lisp) helps people realize.

This:

    (define (foo n)
      ( . . . ))

. . . is just syntax sugar for this:

    (define foo
      (lambda (n)
        ( . . . )))

The fact that the syntax sugar is all many languages expose to the programmer doesn't change that fact, and the one-line restriction on "lambdas" in Python seems quite arbitrary.

Giving people concise syntax for passing anonymous functions allows one to implement a lot of control-flow operations, and combinators from functional programming, as libraries, rather than language constructs.

In python, although they could technically be done as libraries, from a syntactic point of view, having to declare named functions and pass them explicitly as arguments rather defeats the elegance of the approach.

So instead we have special features and syntax added to the language, like with statements and list comprehensions, which are limited special cases of what can be expressed more generally with a nice syntax for passing closures as arguments.

Not that it necessarily matters, there's always a pythonic way to do the equivalent thing. Although a lot of the time it's more imperative, and my taste is for functional programming idioms where possible.

Yes, Python's functions are meant to be named.