> There are certainly other potential issues with closing over mutable variables.
I don't really like your use of the word variable here. Do you mean objects or bindings?
> However, if Python's variables were immutable, it would have to create a new scope for the for body
(I'm guessing bindings) Sure, but it's not like immutable bindings are required for that, just go the internal iterator route and you're set for most cases.
> Sure, but it's not like immutable bindings are required for that, just go the internal iterator route and you're set for most cases.
Right. That's why in my first comment, I said that not creating a new lexical scope for the loop body is the real issue here. I didn't make it especially clear that it doesn't matter whether you do that using an internal iterator or by giving for statements a statement-level scope, but of the two examples I gave of languages with mutable bindings and the "correct" (IMO) behavior here, Perl 5 uses the statement-level scope approach, while Perl 6 uses the internal iteration approach(for is very light syntactic sugar for map).
I believe I misread your previous comment as suggesting that mutability was the key issue here. In response to that, I wanted to point out that even in a situation with immutable bindings, one still needs to have each iteration's binding be a different binding to deal with this case.
I don't really like your use of the word variable here. Do you mean objects or bindings?
> However, if Python's variables were immutable, it would have to create a new scope for the for body
(I'm guessing bindings) Sure, but it's not like immutable bindings are required for that, just go the internal iterator route and you're set for most cases.