[Python-Dev] Improve Python for embedding
Guido van Rossum
guido at python.org
Mon Dec 22 15:03:40 EST 2003
> [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/)
More information about the Python-Dev
mailing list