Creating a local variable scope.

Dave Angel davea at
Sat Sep 19 15:05:14 CEST 2009

Johan Grönqvist wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Sean 
> DiZazzo skrev:
>> I would do something like this:
>>>>> class Namespace(object):
>> ...     pass
>> ...
>>>>> n = Namespace()
>>>>> n.f = 2
>>>>> n.g = 4
>>>>> print f
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in ?
>> NameError: name 'f' is not defined
>>>>> print n.f
>> 2
> I like this solution. This also minimizes the extra code if I would 
> want to explicitly delete the bindings, as I would only need one line 
> to delete the Namespace object.
> Thanks!
> Johan
> </div>
Even simpler solution for most cases, use longer names.  If the name 
means something in the local context, and the next context is different, 
you presumably will use a deliberately different name.  In your earlier 
example, if you called them row and column, you ought to notice if you 
used row instead of column in the later "scope".

One thing people don't notice when they ask the compiler to catch all 
these types of problems is that there are lots of things the compiler 
can't check.  In Python if you delete a previous attribute, you'll get 
an error when trying to read that attribute, but not when trying to 
write it.  Because as soon as you write it, you're declaring it again.

I spent years in C++ and Java environments, as well as many other 
languages that enforced some of these rules.  But once you get used to 
the notion that the system won't check you, you're less likely to fall 
into the traps that always remain in those other languages -- write your 
own code defensively.  And that means that for anything bigger than 
throw-away samples, use real names for things.,

I spent time years ago in Forth, where a name could be almost anything 
(no embedded spaces), and where syntax in the language was almost 
non-existent, and you could define first class language constructs 
inline, no sweat.  It really freed the mind to think about the problem, 
instead of the language and its idiosyncracies.


More information about the Python-list mailing list