[Python-Dev] Improve Python for embedding
Guido van Rossum
guido at python.org
Mon Dec 22 14:33:29 EST 2003
> I find the current situation when 'embedding' Python rather unsatisfying.
I'm interested in improve it. Can you explain what exactly your
'embedding' requirements are?
> 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.
> 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?
> 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().
> - 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 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.
Go ahead, but count me out of the wiki -- wikis don't work for
discussions for me.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list