Immutability and Blocks, Lambdas and Closures
algorithm.com.au
algorithm.com.au
In either Perl 5 or Perl 6, both of which use mutable variables, the corresponding code does the right thing (although Perl 5 only does so if you actually use a newly defined lexical: as in "for my $m ('do', 're', 'mi') {...}").
Unfortunately, Python's implicit declaration of lexicals means that it would be difficult to do a for loop with an iteration variable that isn't lexical to the loop body if that was the default (where would you put the "nonlocal" statement?).
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.
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 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.
For my part, I always found having block scope inside conditionals to feel weird.