Am 27.12.2012 16:10, schrieb Nick Coghlan:
Additional configuration is handled via separate API calls::
Py_SetProgramName() (call before Py_Initialize()) Py_SetPath() (optional, call before Py_Initialize()) Py_SetPythonHome() (optional, call before Py_Initialize()???) Py_SetArgv[Ex]() (call after Py_Initialize())
[...]
The only configuration that currently absolutely needs to be in place before even the interpreter core can be initialised is the seed for the randomised hash algorithm. However, there are a couple of settings needed there: whether or not hash randomisation is enabled at all, and if it's enabled, whether or not to use a specific seed value.
The proposed API for this step in the startup sequence is::
void Py_BeginInitialization(Py_CoreConfig *config);
Like Py_Initialize, this part of the new API treats initialisation failures as fatal errors. While that's still not particularly embedding friendly, the operations in this step *really* shouldn't be failing, and changing them to return error codes instead of aborting would be an even larger task than the one already being proposed.
The new Py_CoreConfig struct holds the settings required for preliminary configuration::
typedef struct { int use_hash_seed; size_t hash_seed; } Py_CoreConfig;
Hello Nick, we could use the opportunity and move more settings to Py_CoreConfig. At the moment several settings are stored in static variables: Python/pythonrun.c static wchar_t *progname static wchar_t *default_home static wchar_t env_home[PATH_MAX+1] Modules/getpath.c static wchar_t prefix[MAXPATHLEN+1] static wchar_t exec_prefix[MAXPATHLEN+1] static wchar_t progpath[MAXPATHLEN+1] static wchar_t *module_search_path static int module_search_path_malloced static wchar_t *lib_python = L"lib/python" VERSION; PC/getpath.c static wchar_t dllpath[MAXPATHLEN+1] These settings could be added to the Py_CoreConfig struct and unify the configuration schema for embedders. Functions like Py_SetProgramName() would set the members of a global Py_CoreConfig struct. Christian