[Python-Dev] Improve Python for embedding
Tom Emerson
tree at basistech.com
Mon Dec 22 15:06:42 EST 2003
Guido van Rossum writes:
> > Indeed. See patch 849278 for some of the work we did to deal with this.
>
> This mostly removes the use of the PYTHONXXX environment variables.
> Can you explain why you don't want these to work?
If the user installs our application and has a separate Python
installation on their machine for which they use those environment
variables, bad things can happen. I do not want to be in a position
where I'm told our app doesn't work because of environment variables
we have no control over, and it is the Wrong Answer to tell the user
to change their environment.
> Also note that you can already disable *all* use of the environment
> (not just in Py_Initialize()) by setting the global
> Py_IgnoreEnvironmentFlag to a non-zero value. I'd reject that part of
> the patch for that reason.
I did not know about or notice this flag when I made the changes ---
in all the places I looked at the time the environment variables were
read without such a check, at least as I remember. It certainly makes
more sense to use the built in support.
> Py_SetSysPaths() might be a valuable addition, but the game you play
> with the prefiX name is abject. :)
Sure, whatever. These were made for our own use and later submitted,
They can be cleaned up as needed.
> What do you suggest the interpreter should do instead of calling
> abort()? This is only called in response to *fatal* errors --
> situations where raising an exception is *not* an acceptable
> alternative for various reasons (maybe because it's in a piece of code
> that is part of the implementation of exceptions, or maybe because a
> corruption is detected in the very interpreter environment that's
> needed to raise an exception).
During initialization if there is a fatal error I can just disable the
functionality that uses the interpreter --- having my app abort
because Python cannot initialize for whatever reason is a Bad
Thing. Similarly with writing messages directly to stderr: I do not
necessarily want our users to see these since they don't know what to
do with them.
> Anout the only alternative I can think of would be a longjmp() call
> to a handler you have set up, but that can't be safe when the fatal
> error is discovered in a different thread.
In our use of Python we build without threads, so the longjmp() would
work. In the case of threads all bets are off.
> What's your embedding environment? Why do you want to use Py_Main()
> at all?
I don't use Py_Main() in my embedding (multiple Unix flavors, 32- and
64-bit, and Win32 and Win64)... I wasn't reading closely enough.
-tree
--
Tom Emerson Basis Technology Corp.
Software Architect http://www.basistech.com
"Beware the lollipop of mediocrity: lick it once and you suck forever"
More information about the Python-Dev
mailing list