[Python-Dev] Improve Python for embedding

[Guido van Rossum]

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

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 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 just
> > after Py_Initialize() 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/)