Question about envvars

Stephen J. Turner sjturner at ix.netcom.com
Mon Jun 7 17:24:33 EDT 1999


Hi Rob,

> Boy I was excited to get a reasonable explaination so quickly, but alas,
> it still does not work.  Here is my test script:
> 
> #!/usr/local/bin/python
> 
> import MDIreg
> 
> reg = MDIreg.FileRegistry(1,1)
> reg.exportEnvVars()
> 
> import os
> print "child has it : "
> os.system("env | grep MDI_REG_VERSION")
> print "but do I have it? :"
> print os.environ['MDI_REG_VERSION']
> 
> ---
> 
> I am interested in this "MDI_REG_VERSION" envvar which gets exported by
> my library.  Here is the output:
> 
> child has it :
> MDI_REG_VERSION=10.0
> but do I have it? :
> Traceback (innermost last):
>   File "regtest.py", line 12, in ?
>     print os.environ['MDI_REG_VERSION']
>   File "/usr/local/lib/python1.5/UserDict.py", line 12, in __getitem__
>     def __getitem__(self, key): return self.data[key]
> KeyError: MDI_REG_VERSION

Oops!  I just realized that the site module, which is imported by
default when the Python interpreter starts, imports the os module -- so
by the time your script begins to execute, it's already too late.  Just
for grins, you could try disabling the site module by adding the '-S'
option to the Python command line, as in:

#!/usr/local/bin/python -S

I'm not advocating this approach, since it's generally a good idea to
import the site module.  I'd just like to know if it works for you.

> Any other ideas?  Any way to tell the os/posix module to "refresh"?

None that I can see from looking in Modules/posixmodule.c.  Sorry.

> By the way, thanks for the library implementation suggestion, but I must
> keep it the way it is, because other c, and c++ (at the class level)
> programs access this library.

OK, how 'bout this?  Suppose you added a virtual "putenv" method to your
FileRegistry C++ class whose default implementation was to call the
global putenv function.  Then in your Python C extension, you could
subclass FileRegistry and override the putenv method with one that
modifies os.environ as described in the prior post.

Regards,
Stephen

--
Stephen J. Turner <sjturner at ix.netcom.com>




More information about the Python-list mailing list