Eric Snow <ericsnowcurren...@gmail.com> added the comment:
## Background ## `_Py_Identifier` (and `_Py_IDENTIFIER()`, etc.) was added in 2011 [1][2] for several reasons: * provide a consistent approach for a common optimization: caching C-string based string objects * facilitate freeing those objects during runtime finalization The solution involved using a static variable defined, using `_Py_IDENTIFIER()` near the code that needed the string. The variable (a `_Py_Identifier`) would hold the desired C string (statically initialized) and the corresponding (lazily created) `PyUnicodeObject`. The code where the `_Py_Identifier` was defined would then pass it to specialized versions of various C-API that would normally consume a C string or `PyUnicodeObject`. Then that code would use either the C-string or the object (creating and caching it first if not done already). This approach decentralized the caching but also provided a single tracking mechanism that made it easier to clean up the objects. Over the last decade a number of changes were made, including recent changes to make the identifiers per-interpreter and to use a centralized cache. [1] https://github.com/python/cpython/commit/afe55bba33a20f87a58f940186359237064b428f [2] https://mail.python.org/archives/list/python-...@python.org/message/FRUTTE47JO2XN3LXV2J4VB5A5VILILLA/ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46541> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
