Default scope of variables

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu Jul 4 07:32:29 CEST 2013


On Thu, 04 Jul 2013 14:07:55 +1000, Chris Angelico wrote:

> On Thu, Jul 4, 2013 at 1:27 PM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> With respect to the Huffman coding of declarations, Javascript gets it
>> backwards. Locals ought to be more common, but they require more
>> typing. Locals are safer, better, more desirable than globals, and so
>> it should be easier to use locals than globals, not the other way
>> around. Having to declare "give me the safe kind of variable", while
>> getting the harmful[1] kind of variable for free, strikes me as
>> arse-backwards. Lazy, naive or careless coders get globals[2] by
>> default or accident. That's bad.
> 
> I agree that Javascript has it wrong, but not quite for the reason you
> say. The advantage of declaring locals is a flexibility: you can have
> multiple unique variables with the same name in the same function.

Well, if I ever have more than 63,000,000 variables[1] in a function, 
I'll keep that in mind. Until then, I'm pretty sure you can trivially 
avoid name clashes with globals that you wish to avoid clashing with.

Accidental shadowing can be a problem, but I've never heard of anyone 
saying that they were *forced* to shadow a global they needed access to. 
Just pick a different name.


> Python lets you do that across but not within functions.
> 
> But Javascript/ECMAScript/whatever doesn't give you that. A var
> declaration makes it function-local, no matter where the declaration is.
> That's pointless. C++, on the other hand, lets you do this:
> 
> void somefunc() {
>     for (int i=0;i<10;++i) {
>         // do something with outer i
>         for (int i=0;i<4;++i) {
>             // do something with inner i
>         }
>         // outer i is visible again
>     }
>     // neither i is visible
> }

That's truly horrible. If the cost of this "flexibility" is that I'll 
have to read, and debug, other people's code with this sort of thing, I'm 
happy to be less flexible. For what possible reason other than "because I 
can" would you want to use the same loop variable name in two nested 
loops?

I'm not suggesting that C++ should prohibit it. But just because a 
language allows something doesn't make it a *feature*. I can write this 
in Python:

a = a = a = a = a = 1

and it works, but the ability to do so is hardly a feature. It's just a 
side effect of how Python works.

I believe that the function is the right level for scope changes, not to 
large, not to small. I'm not even sure I like the fact that generator 
expressions (in Python 2 & 3) and list comprehensions (in Python 3) 
introduce their own scope.


 
[...]
> Granted, this flexibility is mostly of value when writing huge functions
> with complex nesting, but it is something that I find convenient.

"This feature is mostly of value when poking myself, and any developers 
who have to maintain my code after I'm gone, in the eye with a red-hot 
poker."




[1] Based on empirical evidence that Python supports names with length at 
least up to one million characters long, and assuming that each character 
can be an ASCII letter, digit or underscore.

-- 
Steven



More information about the Python-list mailing list