On Thu, Feb 3, 2022 at 6:31 AM Victor Stinner <vstinner@python.org> wrote:
On Wed, Feb 2, 2022 at 11:43 PM Eric Snow <ericsnowcurrently@gmail.com> wrote:
My plan is to replace our use of _Py_IDENTIFIER() with statically initialized string objects (as fields under _PyRuntimeState). That involves the following:
* add a PyUnicodeObject field (not a pointer) to _PyRuntimeState for each string that currently uses _Py_IDENTIFIER() (or _Py_static_string())
In bpo-39465, I made the _PyUnicode_FromId() compatible with running sub-interpreters in parallel (one GIL per interpreter).
A "static" PyUnicodeObject would have to share the reference count between sub-interpreters, whereas Py_INCREF/Py_DECREF are not thread-safe: there is lock to prevent data races.
Is there a way to push the "immortal objects" strategy discussed in bpo-40255? The deepfreeze already pushed some functions related to that, like _PyObject_IMMORTAL_INIT() in the internal C API. Moreover... deepfreeze already produces "immortal" PyUnicodeObject strings using the "ob_refcnt = 999999999" hack.
IMO we should decide on a strategy. Either we move towards immortal objects (modify Py_INCREF/Py_DECREF to not modify the ref count if an object is immortal), or we make sure that no Python is shared between two Python interpreters.
Either we come to an agreement as a group (for against the concept and then how to do it), or if there's a stalemate it goes to the SC (with potentially a PEP to properly explain the nuances of the proposed solution). -Brett
I'd also like to actually get rid of _Py_IDENTIFIER(), along with other related API including ~14 (private) C-API functions. Dropping all that helps reduce maintenance costs.
Is it required by your work on static strings, or is it more about removing the API which would no longer be consumed by Python itself?
If it's not required, would it make sense to follow the PEP 387 deprecation (mark functions as deprecated, document the deprecation, and wait 2 releases to remove it)?
Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FFQ6N7K2... Code of Conduct: http://python.org/psf/codeofconduct/