[Python-Dev] LOAD_NAME & classes
Mon, 22 Apr 2002 17:23:46 -0400
> I think this is a red herring, and not an argument against what I
Sure it does <wink>. It's one example of the larger point that *any* scope
rules confuse newbies. Lexical scoping doesn't come naturally except to
born Schemers, and indeed didn't come naturally to language designers either
(e.g., early LISPs all had dynamic scoping). So it goes.
> The "only runtime" rules doesn't require dynamic scopes (I agree that
> dynamic scopes would be bad). Dynamic scopes, and your example, mix up
> the call context with the definition context. My example takes the
> definition context, and applies the "is x defined in this scope?" test
> at runtime instead of at compile time. Very different!
Rewrite it trivially:
x = 12
x = 10 # moved the line down
I don't know what you mean by "definition context" (and neither will a
newbie), but any guess I'm likely to come up with wouldn't include the idea
that "x = 10" is now in f's definition context. You would have to spell out
that there are three namespaces at work here, and that what "x" means in f
depends on the dynamic state of two of them, and simply can't be known in
general without running the program. If that's not dynamic scoping, it's
too close for me to believe a distinction is worth making.
BTW, I consider Python's treatment of global vs builtin namespaces dynamic
scoping too, and it's nothing but trouble that globals can mask and unmask
builtins dynamically. I'd rather make globals and builtins act more like
locals now than make locals act more like they're dynamically scoped.
BTW2, I see plenty of UnboundLocalErrors in my own code, and some of those
have occurred when the same name is also in use as a global. It's always
been a logic error due to forgetting to initialize a local, and usually due
to "moving code up" in an editor. It sure wouldn't be doing me any favor to
let such code silently pick up whatever crap happened to be bound to the
same-named global; UnboundLocalError is a fine bug-catcher.