gh-144161: Clarify additional immortalization in free-threaded build #144176
Conversation
…build Clarify that the objects listed in the free-threading HOWTO are additional immortalizations specific to the free-threaded build. This addresses the inconsistency with sys.intern() documentation, which describes the default (mortal) behavior.
|
All commit authors signed the Contributor License Agreement. |
ZeroIntensity
left a comment
ZeroIntensity
left a comment
There was a problem hiding this comment.
I think it would make much more sense to just add a note to sys.intern and PyUnicode_InternInPlace saying that the free-threaded build makes all interned strings immortal.
Prometheus3375
left a comment
Prometheus3375
left a comment
There was a problem hiding this comment.
LGTM, though perhaps in both "Note" blocks I would also highlight "are" in bold as on the picture below.
Doc/c-api/unicode.rst
Outdated
| Note that interned strings are not “immortal”. | ||
| You must keep a reference to the result to benefit from interning. | ||
There was a problem hiding this comment.
Just to avoid double "Note", here's rephrase of the previous paragraph.
| Note that interned strings are not “immortal”. | |
| You must keep a reference to the result to benefit from interning. | |
| Interned strings are not :term:`immortal`. | |
| You must keep a reference to the result to benefit from interning. |
Doc/howto/free-threading-python.rst
Outdated
| --------------- | ||
|
|
||
| In the free-threaded build, some objects are :term:`immortal`. | ||
| The free-threaded build introduces additional :term:`immortal` objects. |
There was a problem hiding this comment.
I think "additional ... objects" is ambiguous. This reads to me as if there are more total objects on the free-threaded build, not that more existing objects are immortal. I would say something like "On the free-threaded build, more objects are made immortal."
Doc/c-api/unicode.rst
Outdated
| then -- as with any other error -- the argument is left unchanged. | ||
| Note that interned strings are not “immortal”. | ||
| Interned strings are not :term:`immortal`. |
There was a problem hiding this comment.
Only strings interned by this function are not immortal, not all interned strings. Let's clarify that.
Doc/c-api/unicode.rst
Outdated
| .. note:: | ||
| In the free-threaded build, all interned strings **are** :term:`immortal`. |
There was a problem hiding this comment.
| .. note:: | |
| In the free-threaded build, all interned strings **are** :term:`immortal`. | |
| .. note:: | |
| On the :term:`free threaded` build, all interned strings are :term:`immortal`. | |
| This may change in the future. |
Ditto for the sys.intern note below.
Doc/library/sys.rst
Outdated
| return value of :func:`intern` around to benefit from it. | ||
|
|
||
| .. note:: | ||
|
|
4 participants
Clarify that the objects listed in the free-threading HOWTO are additional immortalizations specific to the free-threaded build.
This addresses the inconsistency reported in #144161, where
sys.intern()documentation states that interned strings are not immortal, while the free-threading HOWTO suggested otherwise. Both are correct for their respective contexts (default vs. free-threaded builds).Changes follow the suggestion by @Prometheus3375 in the issue discussion.
📚 Documentation preview 📚: https://cpython-previews--144176.org.readthedocs.build/