[Python-ideas] PEP 432: Simplifying the CPython startup sequence

[Nick Coghlan]

I was planning to move most of those settings into the config dict. Both
the core config struct and the config dict would then be stored in new
slots in the interpreter struct.

My preference is to push more settings into the config dictionary, since
those can use the C API and frozen bytecode to do their calculations.

--
Sent from my phone, thus the relative brevity :)
On Dec 28, 2012 6:14 AM, "Christian Heimes" <christian at python.org> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121228/9b80f852/attachment.html>