[Python-Dev] LOAD_NAME & classes

[Michael Gilfix]

On Tue, Apr 23 @ 12:43, Tim Peters wrote:
> Just FYI, "local()" in Perl is very old, and has always used dynamic scoping
> rules.  If you don't wrap local() around a vrbl decl, you get a global vrbl
> instead, and that's also very old.  What's relatively new is the "my()" vrbl
> wrapper, which asks for a lexically scoped vrbl.  What's very new is
> "our()", which I still haven't figured out:
> 
>     An "our" declares the listed variables to be valid globals within
>     the enclosing block, file, or eval.  That is, it has the same scoping
>     rules as a "my" declaration, but does not create a local variable.  If
>     more than one value is listed, the list must be placed in parentheses.
>     The our declaration has no semantic effect unless "use strict vars"
>     is in effect, in which case it lets you use the declared global
>     variable without qualifying it with a package name. (But only within
>     the lexical scope of the our declaration. In this it differs from
>     "use vars", which is package scoped.)
> 
> Anyone want to make a motion that we not ape Perl's scoping rules <wink>?

  The our is akin to declaring something static in C. Except in
Perl, it can apply to an enclosure as well since you can build funcs
dynamically. Yay. I think python's scoping rules work just fine :)

  Has there ever been a discussion about some easy or straight-forward
way of sharing a global instance across modules? For example, in a
gui app, you might want to structure the program such that there's a
global instance app (main.app) of the application that other modules
might want to query. I was never to happy with importing main and then
using main.app... I felt like I wanted to qualify it as a global, like:

  from main import global app

                   -- Mike

-- 
Michael Gilfix
mgilfix@eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html