The real issue is that Python's for construct doesn't create a new lexical scope for the body.
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?).
> 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.
This is why CoffeeScript introduced the "do" keyword. I'd have to agree that, while in Javascript in particular this is considered a rookie mistake, loop variables not being closed over is a rather confusing phenomenon for newcomers.
CoffeScript is a very good language, but in my opinion, it should not be an excuse to not learn and understand such confusing behaviors of javascript. It will eventually bite any such newcomers. Not that you meant this, just saying.
I guess the best way to view CoffeeScript is to treat it as a form of shorthand for JavaScript. A more convenient syntax, but you still need to understand the underlying JavaScript for the purposes of troubleshooting and performance optimising.
Well, I figure you first have to know what the "do" keyword does, what problem it fixes, before you'll be inclined to actually use it, so people diving in without a lack of knowledge shouldn't really be an issue.
This problem was solved brilliantly by Clojure. Everything is immutable by default, and modifications of references happen at explicit points in the flow, with well-defined semantics.
The fundamental ideas come from existing languages, nobody is trying to contradict that. Clojure builds on the past, but its rich abstractions for concurrency and persistent data structures make it unique.
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?).