> And you can't do something like this in a clean way:

That's what nonlocal is for: https://docs.python.org/3/reference/simple_stmts.html#the-no... Just stick "nonlocal counter" in your function and it works.

True. But nonlocal is relatively new.

Also nonlocal implies that other variables are local, which is not true. E.g., the following works without "nonlocal" keyword:

    counter = [0]

    def add(n):
      counter[0] += n

    add(1)
    add(2)

(This used to be my workaround.)

Yup, relatively new. Only around since python 3.0, for the last 12 years ;-)

nonlocal implies that you are reassigning a variable outside of the local scope.

Your example works because you are mutating an existing object, not reassigning a new one.

It's a disingenuous comparison IMO.

> My main problem with Python: passing a temporary closure to a function is very messy.

What's messy about it?

Python syntax is built around indentation. Try to properly indent a function that you pass to another function. And what if you have to pass two such functions? Where do you place the comma that separates both arguments?

You can't define a function via 'def' and pass it as an argument at the same time. You can do it via 'lambda' though (which doesn't require any indentation since it's just an expression), what's the problem with it?

    >>> (lambda f: lambda x: f(x) * 2)(lambda x: x + 1)(100)
    202

So the problem is that you can only inline expressions; you can't inline let-blocks (assignments), or multiple statements. The usefulness is very limited.

You pass functions just like any other argument.

clos = 42

def foo(x): return x + clos

def bar(y): return y * clos

higher_order(foo, bar)

What's so hard about that?

Here's a challenge: try inlining the foo and bar in the call (because this is how functions are typically composed in functional programming)

You could do this with a lambda construct in Python; but this only works if the function has a single expression-statement; it doesn't work e.g. when you have a bunch of assignments inside the function you are inlining.

>Here's a challenge: try inlining the foo and bar in the call (because this is how functions are typically composed in functional programming)

Sure, it's ugly but I think it's a silly challenge. Complex functions defined in the function call are un-maintainable anyway IMO.