> [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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4