taleinat at gmail.com
Thu Apr 10 17:23:58 CEST 2008
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.
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
"var" for local variable declaration, and it has closures, and it has
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...).
More information about the Python-ideas