[Python-Dev] Re: [PyWX] RE: PyWX (Python AOLserver plugin)

[Guido van Rossum]

> 3.  We address sys.argv (is this just a bug on our part maybe?)

Probably.  The variables are not shared -- thir initial values are the
same.

> 4.  Can we address the os.environ leak similarly?  I'm trying to 
> think of cases where a CGI really should be allowed to add to
> the environment.  Maybe someone needs to set an environment variable
> used by some other program that will be run in a subshell.  If
> so, maybe we can somehow serialize activities that modify os.environ
> in this way?

You each get a copy of os.environ.

Running things in subshells from threads is asking for trouble!

But if you have to, you can write your own os.system() substitute that
uses os.execve() -- this allows you to pass in the environment
explicitly.

You may have to take out (override) the code that automatically calls
os.putenv() when an assignment into os.environment is made.

> Idea:  If Python forks a subshell, it inherits the parent
> process's environment.  That's probably the only time we really want
> to let someone modify the os.environ -- so it can be passed to
> a child.  What if we serialized through the fork somehow like so:
> 
> 1.  Python script wants to set environment, makes call to os.environ
> 1a. We serialize here, so now we are single-threaded
> 2.  Script forks a subshell.
> 2b. We remove the entry we just added and release mutex.
> 3.  Execution continues.
> 
> This probably still won't work because the script might now expect
> these variables to be in the environment dictionary.
> 
> Perhaps we can dummy up a fake os.environ dictionary per interpreter
> thread that doesn't actually change the true UNIX environment?

See above.  You can do it!

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)