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.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
