homepage

I'm building a dll add-in (on Windows) in which I want to use the installed version of Python, not provide my own installation. When py_initialize fails it appears to call exit(). This doesn't seem very friendly behaviour for an embeddable scripting language as the host application is terminated (out of my control).
So my request is that either py_initialize is changed to return a code indicating failure or sucess or another function is added to th api to test if the installation is good or not. That way I can report to the user that there is a problem in the python installation rather than apparently crashing the host app.
Currently the only strategy I've thought of to get around this is to fork a seperate process, and inspect it after a delay to see if it is running (indicating that py_initialize hasn't failed), terminate the new process and then call py_initialize in the host application process.
This has been raised before but only in terms of consistency with the documentation, not about if a embeddable scripting engine should terminate the hosting process without regard to that host.
Many thanks,
David

If we add a (yet another) variant of Py_Initialize, I would suggest we make it extensible by passing it a struct of arguments (so that the struct can be augmented without breaking compatibility).

This problem easily happen when there is no python installation and there is standalone python application compiled with py2exe or cx_Freeze (e.g. Mercurial). Such application have pythonXX.dll in its directory. But its python library can not be loaded normally. So an application, which loads pythonXX.dll to check if python is available and uses it if possible, is terminated when loading python.
Vim uses python as embedding scripting language. Vim loads pythonXX.dll when :python command is used. And this problem is reported occasionally.

Changing this isn't really feasible with the current design of the initialisation code - we call Py_FatalError in various places because we don't have the infrastructure set up to do anything else.
PEP 432 should help (and the basic design there still seems sound), since we'll have the core interpreter up and running much earlier, and hence be able to make use of the non-fatal exception machinery. However, it would still mean carefully reviewing everywhere we call Py_FatalError and ensuring there's an error returning path back up to the embedding application.
Unfortunately, I don't know when I'm going to find time to get back to that, and the startup process is sufficiently arcane that it wouldn't be a quick process for someone else to come up to speed on the current state of the draft implementation :(

> I'm building a dll add-in (on Windows) in which I want to use the installed version of Python, not provide my own installation. When py_initialize fails it appears to call exit(). (...)
This issue has been fixed by the PEP 587 in bpo-36763: Py_InitializeFromConfig() now returns a PyStatus structure which is a success, error message or an exit code. The caller can decide how to handle it.