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

Guido van Rossum guido at python.org
Mon Dec 22 14:54:01 EST 2003

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?

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.

Py_SetSysPaths() might be a valuable addition, but the game you play with the prefiX name is abject. :)

> 1. Careful preparation (hacking?) of environment variables is needed to > avoid that PyInitialize() takes the default actions needed for the > standard Python interpreter (for example, to avoid the default sys.path).

I've done this in the patches submitted (by a coworker) above. The idea is to separate the embedded interpreter completely from the environment. > 2. A suggestion from /F on c.l.p was to change pythonw.exe so that > instead of hiding all output to stderr a console window would be opened > to show the tracebacks. This requires to construct an object with a > 'write' method doing all this magic, and it must be done after the call > to PyInitialize() and before PyRunSimpleFile(). Now, looking at the > code of PyMain(), it seems impossible without rewriting most of the > code. Yes, this is a problem with the embedded interpreter where errors may be written to stderr without regard to the calling application. Further, it is possible for the interpreter to call abort(), which is even worse.

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). 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.

> Possible improvements I currently can think of are: > > - Provide a function like PyInitializeEx(), which accepts parameters > specifying an initial sys.path, optimize flag, verbose flag, and so on.

See the patch. > - Split PyMain() into 2 functions PyMainPrepare() and PyMainRun(), > or let PyMain() accept a callback function which will be called just > after PyInitialize() has been run. Yup.

What's your embedding environment? Why do you want to use Py_Main() at all?

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list