[Python-Dev] Improve Python for embedding (original) (raw)

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 PyInitialize()) by setting the global PyIgnoreEnvironmentFlag 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.

PySetSysPaths() 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 PyMain() 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