Thomas Heller writes:
I find the current situation when 'embedding' Python rather unsatisfying.
Indeed. See patch 849278 for some of the work we did to deal with this.
1. Careful preparation (hacking?) of environment variables is needed to avoid that Py_Initialize() 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 Py_Initialize() and before PyRun_SimpleFile(). Now, looking at the code of Py_Main(), 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.
Possible improvements I currently can think of are:
- Provide a function like Py_InitializeEx(), which accepts parameters specifying an initial sys.path, optimize flag, verbose flag, and so on.
See the patch.
- Split Py_Main() into 2 functions Py_Main_Prepare() and Py_Main_Run(), or let Py_Main() accept a callback function which will be called jsut after Py_Initialize() has been run.
Yup.
I'm not ready to write a PEP, but if there are people sharing this feeling I would suggest we create a wiki entry somewhere acting as a temporary brainstorming area.
Absolutely: count me in. -tree -- Tom Emerson Basis Technology Corp. Software Architect http://www.basistech.com "Beware the lollipop of mediocrity: lick it once and you suck forever"