If you feel the need to use a multi line lambda you should be using a regular function.

This is a code smell for sure.

This is the silliest thing I see paroted. Anonymous functions are there for one offs. Sometimes a one-off is two lines. Breaking it out into a separate function is ridiculous.

You end up seeing functions declared within functions so that people can work around this limitation and it is grotesque.

Regular functions definitions can't be used as expressions.

You are basically saying that one should never need a multi-line lambda. Obviously, I disagree.

If you need to express something complex enough that you can't do it in a single statement in Python, it deserves to have a name (or more likely, it already has one in the standard library).

But python for loops can and typical do have multiple lines, yet that “block” inside the for loop doesn’t have a name. The fact that the body of a for loop can have multiple lines but an anonymous function cannot is a purely arbitrary syntax limitation, and the principle you stated ought to apply (or not apply) equally to both use cases.

This doesn't follow: for loops are there specifically for cases of the complexity that can't be handled by other constructs (like comprehensions). Anonymous functions are not, for the complex cases you give the construct a name.

It's a very intentional language limitation, much as semantic whitespace is an intentional limitation.

And there is actually a language difference. A for loop is a statement. A lambda is an expression. Python doesn't let you put statements into expressions.

I tentatively disagree with both of you.

I've sometimes wondered whether code would be universally clearer if all you could do in a loop is have a one-liner or call another function/method (mainly when looking at my own code within loops and thinking WTF!!!).

Would probably cause issues when teaching programming though. It would be interesting to have a compiler switch that enforced this...

What comes to mind immediately is that you would lose the ability to `break` unless you had another convention like returning a specific value to indicate you want to break.

If you are limited to one statement you could still do something along the lines of the following (no particular language):

  foreach ( $item in $list )
  {
    if ( 1 == some_function( $item ) )
    {
      continue;
    }
    else
    if ( 2 == some_function( $item ) )
    {
      break;
    }
    else
    {
      another_function( $item );
    }
  }

But I would immediately concede that it is starting to miss the entire point of why it was enforced in the first place...

I actually like this style (or similar if not quite as extreme). I find it's much clearer what's going on.

Thanks for writing this, that clarifies the issue more clearly and concisely than what I had in mind.

I will mention a core aspect of my argument, to add to your point.

When you make a named function and then use it separately somewhere else, there is a loss of locality. The logic is now further from its point of use. This is a cost, and sometimes it is an unreasonable one.

i'd agree with this, except you can have a function within a function in Python to limit scope and keep it local. yeah, you have to define it before the code using it - sometimes this feels like a boon though, especially compared to huge inline lambdas. so over time, my annoyance with this has decreased, and it doesn't bother me anymore.

I've started to use Python type hints, but even with typing I like to label my names things that describe local concerns (types are often more general than what you mean to say), and sometimes I'll deliberately shorten the names to make a Python lambda fit where in another language with bracketing I'd just take an extra 1-2 lines and format the line differently.

I've written snippets or data structures one way or another as I'm sure many have, and in my experience the results have been mixed. This and the fact that reduce has no bearing on your app architecture, I do see this as arguing over a small and vague gain or loss.

Large anonymous functions are very much a thing in JavaScript.

This trend will gradually fade into the history books. Just because it’s a thing doesn’t mean it’s a good one.

Large anonymous functions are a thing in every modern language I can think of except python. It’s the only sensible solution in the case of functional method chaining, which is much more readable than nested comprehensions. Python just got this one wrong.

Large anonymous functions are rarely used in rust, go, python, java (streams instead), or cpp.

Streams and repeated application of short anonymous functions are a much better solution to the method chaining issue.

If js supported better streaming tools, they'd be less common in js too.

> Regular functions definitions can't be used as expressions

I’m having a difficult time understanding what you mean here. Can you offer an example?

I have never felt compelled to write a multi line lambda.

Python can't replicate the structure of this JavaScript code:

  fooBaz(x => {
    // multiple lines of logic
  })

In python, you are forced to move the logic away from the point of usage, which means you lose some locality. This loss is sometimes not worth getting a "name" for the logic.

Of course, sometimes it is better to create a named function away from the point of usage, but I don't think that is always the case.

Multi-line lambda is not code smell.

There are a lot of cases like GUI programming where you need a lot of handlers which are suitable for lambda because they don't have a good name, and should never be called manually, and often they have multi-lines of codes.