This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients eric.snow, serhiy.storchaka, vstinner
Date 2022-01-26.22:01:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1643234478.55.0.83043378581.issue46541@roundup.psfhosted.org>
In-reply-to
Content
## 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-dev@python.org/message/FRUTTE47JO2XN3LXV2J4VB5A5VILILLA/
History
Date User Action Args
2022-01-26 22:01:18eric.snowsetrecipients: + eric.snow, vstinner, serhiy.storchaka
2022-01-26 22:01:18eric.snowsetmessageid: <1643234478.55.0.83043378581.issue46541@roundup.psfhosted.org>
2022-01-26 22:01:18eric.snowlinkissue46541 messages
2022-01-26 22:01:18eric.snowcreate