Is global really global.

[Delaney, Timothy]

>     global options
>     options = read_options(parfile)

What you're doing here is declaring that options is placed into the global
namespace of the current module. The
	global options
call here shouldn't be necessary (it is only necessary when inside another
local namespace such as a function).

> a module called "Peaks.py".
> 
> 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."        
> 
> 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

Okay - what is happening here is that you need to import the Peaks module to
get access to the options reference.

(in Locator.py)

import Peaks

if Peaks.options.no_coda:
	...

or

(in Locator.py)

from Peaks import options

if options.no_coda:
	...

One final option is to stick the options into the __builtins__ module, which
makes it *truly* global, but this is a Bad Thing (TM) in most cases.

(in Peaks.py)

__builtins__['options'] = read_options(parfile)

(in Locator.py)

if options.no_coda:
	...

Tim Delaney
Avaya Australia