Slight lambda-in-closures issue

[dplepage]

This is great stuff!

In the not-so-obvious python tutorial, one thing caught me eye - you say that the lambda-closure problem doesn't apply to generators, but it actually does. Your example appears to work because each function returned by the generator is going to return the current value of n, which indicates how far along in generator you've gotten. The list example fails because the whole list is evaluated; the generator example "succeeds" because when you call the ith function, n is still only equal to i. To see this in action:

>>> my_gen = (lambda:n for n in range(5))
>>> a = next(my_gen)
>>> a() # a() returns 0 because that's what n is right now
0
>>> a()
0
>>> # Advancing the generator increases n by one
>>> b = next(my_gen)
>>> b() # b returns 1, as expected
1
>>> a() # but now a returns 1, too
1
>>> # calling list(my_gen) will advance the generator to the end
>>> _ = list(my_gen)
>>> a(), b() # now n is 4
(4, 4)

[rasbt]

Thanks for the comment! I am a little bit unsure what exact point you want to emphasize. Like you said, the whole list is evaluated and the variable i will therefore be 4 for the lambda function. When you do a _ = list(my_gen), isn't it the same as using the list in the first place then !?

[dplepage]

You currently say "This, however, does not apply to generators"; I'm pointing out that it does apply to generators - the functions returned by my_gen are still all returning the variable from the closure.

You'll be fine as long as you only ever use the functions within the loop over the generator, but if you save any of them, you'll find that their values have changed after the end of the loop:

>>> my_gen = (lambda: n for n in range(5))
>>> for i,l in enumerate(my_gen):
...     if i == 1: x = l # keep a reference to the 2nd function, which returned 1
...     print(l())
...
0
1
2
3
4
>>> x() # the 2nd function now always returns 4
4

So even when you're using generators, you probably still want to use (lambda x=n: x for n in range(5)).

[rasbt]

What I basically tried to say with the statement ("This, however, does not apply to generators") was that the variable inside the lambda-generator construct won't be set to the last value of the range object since the generator - in contrast to the list - was not evaluated completely (or "exhausted"/ "consumed"). But as we are progressing forward it will return the current state that the variable n has in the closure.

I think I should change the sentences

[
"Since the list is already constructed when we for-loop through the list, it will be set to the last value 4."
...
"This, however, does not apply to generators"]

into something like

[
Since the list comprehension has already been constructed and evaluated when we for-loop through the list, the closure-variable will be set to the last value 4.

However, by using a generator expression, we can make use of its stepwise evaluation (note that the returned variable still stems from the same closure, but the value changes as we iterate over the generator). ]