Each Answer to this Q is separated by one/two green lines.
I just ran across Eric Lippert’s Closing over the loop variable considered harmful via SO, and, after experimenting, realized that the same problem exists (and is even harder to get around) in Python.
>>> l =  >>> for r in range(10): ... def foo(): ... return r ... l.append(foo) ... >>> for f in l: ... f() ... 9 9 9 # etc
and, the standard C# workaround doesn’t work (I assume because of the nature of references in Python)
>>> l =  >>> for r in range(10): ... r2 = r ... def foo(): ... return r2 ... l.append(foo) ... >>> for f in l: ... f() ... 9 9 9 # etc
I recognize that this isn’t much of a problem in Python with its general emphasis on non-closure object structures, but I’m curious if there is an obvious Pythonic way to handle this, or do we have to go the JS route of nested function calls to create actually new vars?
>>> l =  >>> for r in range(10): ... l.append((lambda x: lambda: x)(r)) ... >>> for f in l: ... f() ... 0 1 2 # etc
One way is to use a parameter with default value:
l =  for r in range(10): def foo(r = r): return r l.append(foo) for f in l: print(f())
0 1 2 3 4 5 6 7 8 9
This works because it defines an
foo‘s local scope, and binds the default value to it at the time
foo is defined.
Another way is to use a function factory:
l =  for r in range(10): def make_foo(r): def foo(): return r return foo l.append(make_foo(r)) for f in l: print(f())
This works because it defines
make_foo‘s local scope, and binds a value to it when
make_foo(r) is called. Later, when
f() is called,
r is looked-up using the LEGB rule. Although
r is not found in the local scope of
foo, it is found in the enclosing scope of