Aaron Watters wrote:
I know it's too late but as long as py3k will break everything, why not add explicit introduction of local variables?
This is one place where Perl actually gets something right with "use strict;" and "my variable=...;"
In particular there is a big conceptual difference between creating a new variable and changing a binding to an existing variable.
You could make this difference explicit by saying
# create local myvariable (error if exists) and assign value var myvariable=value;
# rebind local myvariable (error if doesn't exist) myvariable = value;
This would allow catching a lot of nameerrors at compile time, and also name mistakes which don't show up as nameerrors (like accidentally typing a variable name wrong in such a way that it doesn't fail the test cases, but only fails after deployment...). Any assignment with no associated "my" declaration would automatically be an error at compile time.
[snip] I've worked with Perl more than I would have liked to, and IMO this is useful in Perl mainly because Perl code tends to grow into long functions and/or a lot of top-level code; better management of variables is essential simply because one needs more variables in a single scope to get things done. I was repeatedly surprised to find myself writing very long functions in Perl, unlike my style in every other language, and "use strict" really did catch such errors of mine many times. I've also recently worked a lot with JavaScript and the "var" thing is HORRIBLE!!! Ok, so after venting some steam, allow me to explain: JavaScript uses "var" for local variable declaration, and it has closures, and it has anonymous functions. Also, note that JavaScript's closures hold variables "by reference" rather than "by value". The result is that if you ever forget to write "var" in a function, you're very likely to end up overriding a variable from an outer scope, or various other problems. Such errors can be extremely hard to debug! Python's current scoping rules are confusing as well. But the lack of anonymous functions means you're more aware of the current scope (and outer scopes). And the "freezing" of variable values in closures makes using closers MUCH simpler and less bug-prone. Empirically, I don't think I've ever been bitten by this in Python, even though I've defined a lot of functions inside functions (inside functions...). - Tal