Is global really global.
Steve Holden
sholden at holdenweb.com
Thu Oct 26 22:00:01 EDT 2000
Steve Juranich wrote:
>
> So far, I really love Python. However, the most confusing part of it for me
> is definitely the whole namespace business.
>
Well, you only have three to worry about at any one time ...
> I'm writing a suite of modules that are supposed to work in concert. In the
> "main" module, I read in a file that specifies all of the run-time paramters
> that the program is supposed to use. Here is where I define the "options"
> structure:
>
> global options
> options = read_options(parfile)
>
> Where the read_options function works a little magic on the file and returns
> the table (one of my own classes) that contains all of the information that
> the user specified in a parameter file (or "parfile"). This all happens in
> a module called "Peaks.py".
>
So options is global _to module main_.
> Later on, I try and test some values in "options" via:
>
> if options.no_coda:
> # Eventually, here's where I'd remove the coda, but for
> # now, just...
> raise NotImplementedError, \
> "I can't deal with the no_coda option yet."
>
> Please ignore the fact that I don't have the option implemented yet. <0.5 wink>
Sure. Some of my best code is the unimplemented stuff.
> The test above happens in a module called "Locator.py". But the above test
> when I try to run it, gives me:
>
> condor (peaks)$ Peaks.py parfile.peaks first_list First
> Traceback (most recent call last):
> File "./Peaks.py", line 75, in ?
> main_loop()
> File "./Peaks.py", line 66, in main_loop
> peaks = Locator.f0_peak_locator(frames)
> File "./Locator.py", line 23, in f0_peak_locator
> if options.no_coda:
> NameError: options
>
That would seem logical, captain. Presumably Locator.py imports the
Peaks module?
> Why is this happenning even though I specified "options" as a global? This
> causes me to suspect that "global" means something different in Python than
> it does in C (which isn't a bad idea).
>
Correct. Global means "not local". It is typically used to indicate in the
code of a function that a reference should be taken to refer to a variable
in the namespace of the surrounding module rather than the namespace of the
function.
By default Python assumes that names in a function are local if they are
assigned to. Here's a demonstration:
Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
IDLE 0.5 -- press F1 for help
>>> def f(a):
print a
print x
x = 3
print x
>>> def g(a):
print a
print x
>>> x = 39
>>> g(12)
12
39
>>> f(12)
12
Traceback (innermost last):
File "<pyshell#12>", line 1, in ?
f(12)
File "<pyshell#5>", line 3, in f
print x
NameError: x
>>>
Note that the reference to x in the second print statement of the f function
is assumed to be local (because of the assigment which follows), while the
reference in teh g function is assumed global, because there is never an
assignment to it.
> Am I misunderstanding the meaning of "global", or is something else afoot?
> How do I work around this? I know using globals isn't good anyway, but I'm
> to the point that I _really_ need to show my professor that I've been doing
> more than sitting on my thumb for the past couple of weeks (read: I need to
> get something done _quickly_).
>
You seem to have understood the essentials pretty well.
The easiest way would be refer to options as a qualifier to the module name
in which it's defined. i.e.:
if Peaks.options.no_coda:
# Eventually, here's where I'd remove the coda, but for
# now, just...
raise NotImplementedError, \
"I can't deal with the no_coda option yet."
There are other ways, all equivalent but avoiding a little verbosity and a
few dictionary lookups. For example, after you've called the read_options
function in your Peaks module, you could just assign the value of the
result to a local variabel called options:
options = Peaks.options
After that, the rest of your code should work as it is.
> Thanks for the help.
>
A pleasure.
> trying-to-adjust-to-life-in-grad-school-ly y'rs,
>
> ----------------------------------------------------------------------
> Stephen W. Juranich sjuranic at ee.washington.edu
> Electrical Engineering http://students.washington.edu/sjuranic
> University of Washington http://rcs.ee.washington.edu/ssli
trying-to-forget-supervising-grad-students-ly y'rs - steve
--
Helping people meet their information needs with training and technology.
703 967 0887 sholden at bellatlantic.net http://www.holdenweb.com/
More information about the Python-list
mailing list