Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.

A lambda also behaves this way; it’s how it captures the closure scope.

Are lambdas different?

I’ve never seen it create a bottle neck, have you?

It will definitely be a problem if you use JIT interpreter like pypy

That's a lot of boilerplate for a closure…

The trivial lambda case is short, and you can do what the parent said if you want to do something that doesn't fit into the trivial lambda case well.

The "lambda" keyword isn't :(

Where's the boilerplate? "def b():" and "() => {}" are both 8 characters.

It is annoying that you have to give the function a name, though.

On the one hand it’s annoying, on the other it enforces a discipline of thought in the same way that having to name variables does.

That’s an interesting principle, something like “a block of code that is complex enough to be written across multiple lines of code ought to be given a name,” but standard idiomatic Python already violates that principle by featuring multiple lines in the body of a for loop. The fact that the body of a for loop can be multiple lines but the “body” of a lambda cannot is an arbitrary syntax inconsistency.

    def b(x):
      return x + 1

vs

    x => x + 1

That's a couple characters over most languages I normally use. Plus lambdas have a number of strange warts and restrictions (no multi-line lambdas?) that leave me feeling that Python really dislikes traditional functional programming constructs.

Python has become less functional over time. It’s also not a particularly good OO language either. It’s really a more descriptive sort of bash that became ubiquitous despite its short comings.