[Python-Dev] Improve Python for embedding

[Guido van Rossum]

> [Thomas Heller]
> >> I find the current situation when 'embedding' Python rather unsatisfying.
> >
> 
> [Guido van Rossum]
> > I'm interested in improve it.  Can you explain what exactly your
> > 'embedding' requirements are?
> 
> see below.

The only clue I find below is that you're trying to inmprove the error
reporting of pythonw.exe, which is certainly laudable, but hardly
qualifies as "embedding" IMO.

> >> 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 guess it depends on the embedding needs.  Some embedded uses would
> > be quite happy with the default sys.path.
> 
> Sure, but others not.

But the only use *you* are interested in is pythonw.exe?

> >> 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.
> >
> > Except for sys.path, you can set most flags directly before calling
> > Py_Initialize(), so I'm not sure if there's a need to pass these into
> > Py_Initialize().
> 
> I want to specify the Python path before calling Py_Initialize(), and I
> don't want it to use *any* environment variables which (again) set the
> flags.  So I thought of Py_InitializeEx() which would take parameters
> specifying these things, and Py_Initialize() could be changed to call
> Py_InitializeEx(NULL), maybe.

If you don't want the environment to be used, set the global
Py_IgnoreEnvironmentFlag before calling Py_Initialize().

> >> 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.
> >
> > I'm not sure what this has to do with embedding -- can you clarify?
> 
> The Python interpreter (dll) embedded into pythonw.exe ;-)
> 
> >
> >> - 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.
> >
> > OK, now I'm confused.  If you're embedding Python, why would you be
> > using Py_Main() at all?
> 
> I'm probably not good at explaining these things.
> 
> I was thinking of pythonw.exe (WinMain.c).  I want to create a Python
> object (an stderr writer), and assign this to sys.stderr, without
> changing too much code.
> 
> Does it make more sense now?

Not quite -- I don't understand why *you* don't want the environment
variables to be used, if all you want is a better pythonw.exe.

If that's your only experience with embedding Python, you can't really
speak for other embedders.

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