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

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 PyInitialize() 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 PyInitializeEx(), 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 > PyInitialize(), so I'm not sure if there's a need to pass these into > PyInitialize().

I want to specify the Python path before calling PyInitialize(), and I don't want it to use any environment variables which (again) set the flags. So I thought of PyInitializeEx() which would take parameters specifying these things, and PyInitialize() could be changed to call PyInitializeEx(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 PyInitialize() and before PyRunSimpleFile(). Now, looking at the >> code of PyMain(), 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 PyMain() into 2 functions PyMainPrepare() and PyMainRun(), >> or let PyMain() accept a callback function which will be called jsut >> after PyInitialize() has been run. > > OK, now I'm confused. If you're embedding Python, why would you be > using PyMain() 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