Eric Snow <ericsnowcurren...@gmail.com> added the comment:
> I looked quickly at _Py_InitializeCore() and I'm not sure > that it's designed to replace an existing configuration. > ... > So maybe for this specific case, _Py_InitializeCore() should > always set Py_HashRandomizationFlag. +1 At the same time, the use of Py_*Flag variables is a little unclear in the PEP 432 world. Under the PEP I'd expect code in CPython to use the core config from the current PyInterpreterState (or even _PyRuntimeState), rather than the global flag variables. So presumably (the PEP doesn't talk about it) the intent of keeping them is to help folks that currently make use of the flags. However, they shouldn't be modifying them after initialization, and under PEP 432 they don't need to set them beforehand (they set values on the config), right? Part of the problem here is that Py_Main() results in all the flag variables getting set (before runtime initialization). However, with the current PEP 432 [internal] implementation those variables are (mostly) never getting set, right? Shouldn't we set all of them, but only at the end of _Py_InitializeCore() (for the sake of extensions/embedders that use them)? In that case we'd need to replace our internal use of Py_HashRandomizationFlag with field on the config struct on _PyRuntimeState. > But it was just one example to show that right now, > _Py_InitializeCore() doesn't seem to support to be called > twice with two different configurations. Are there other things (than how we set that flag) that break in that case? Regardless, what would ensure that it works properly? ---------- nosy: +emilyemorehouse _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33932> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
