PyUnicode_InternFromString does not immortalize the string as the document claims

[yuyichao]

Documentation

The document for PyUnicode_InternFromString currently claimed that

CPython implementation detail: Strings interned this way are made immortal.

However, testing with simple code like,

        auto v = PyUnicode_InternFromString("abcdefg_aaaaa");
        / PyUnicode_InternImmortal(&v);
        printf("immortalized? %d\n", _Py_IsImmortal(v));

suggests that the returned value is not, which is expected based on the code since it calls _PyUnicode_InternMortal rather than _PyUnicode_InternImmortal. If a call to the internal API PyUnicode_InternImmortal was added (as in the commented out code above), then the string is indeed immortalized.

This document was added in #121364 but that PR did not change the behavior of this function. AFAICT, PyUnicode_InternFromString never immortalize the string ever since it was added in #120520.

The only public API that ever immortalized the input string appears to be PyUnicode_InternInPlace and that was changed in #121364 (the one that added the wrong doc) and there doesn't seem to be any public API that immortalize the string anymore. Although this is technically a document issue, I think it might be better to change the behavior of the function instead to match the document.

Linked PRs

• gh-133260: Remove claim that PyUnicode_InternFromString immortalizes #134213
• [3.14] gh-133260: Remove claim that PyUnicode_InternFromString immortalizes (GH-134213) #134883
• [3.13] gh-133260: Remove claim that PyUnicode_InternFromString immortalizes (GH-134213) #134884

[picnixz]

Either it's a doc issue or it's an implementation issue. So I'll let both tags.

[neonene]

cc @encukou

[encukou]

Oh, good catch! Thanks! I did miss that in #121364 :/
Given that 3.13 is in bugfix-only mode, I'll remove the docs note and backport that.

@colesbury: PyUnicode_InternFromString can start immortalizing the string in main and possibly 3.14. Will it help free-threading?