> The real issue is that Python's for construct doesn't create a new lexical scope for the body.
Yes and no, that's what leads the author to notice the "issue", but it does not actually solve the problem (if closing over a mutable environment is to be seen as a problem), it just pushes it back.
It can be argued that loops is the most common case where this is a problem (by quite a long shot) and working around that issue (by creating statement-level scopes or by using internal iterators [0]) would lead to the vast majority of users extremely encountering it. But still...
[0] internal iterators being the reason why Smalltalkers never encounter that issue, and rubyists and modern JS-developers (using Array.prototype.forEach or equivalent library-specific features) rarely do.
There are certainly other potential issues with closing over mutable variables. However, if Python's variables were immutable, it would have to create a new scope for the for body(either with statement-level scopes or by using internal iterators/higher-order functions instead of for statements).
> 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.
Why is this a problem at all? Isn't closing over a set of mutable variables the standard way OOP is shown to reduce to higher-order functions?
I have a great degree of respect for Manuel, and I read his comment, but I still don't see how sticking with only copying free bindings is a problem. That's how function calls in Python/C#/whatever work anyway -- when you pass a parameter in, it's just the reference that's copied, so programmers are familiar with it already.
Yes and no, that's what leads the author to notice the "issue", but it does not actually solve the problem (if closing over a mutable environment is to be seen as a problem), it just pushes it back.
It can be argued that loops is the most common case where this is a problem (by quite a long shot) and working around that issue (by creating statement-level scopes or by using internal iterators [0]) would lead to the vast majority of users extremely encountering it. But still...
[0] internal iterators being the reason why Smalltalkers never encounter that issue, and rubyists and modern JS-developers (using Array.prototype.forEach or equivalent library-specific features) rarely do.