## 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/