[Python-Dev] Re: Last call: mortal interned strings

Tim Peters tim.one@comcast.net
Tue, 20 Aug 2002 01:31:51 -0400


[Oren Tirosh, to Guido]
> I see that this has been checked in.
>
> My version:
>
> 	PyString_InternInPlace - immortal
> 	PyString_Intern - mortal
>
> Your version:
>
> 	PyString_InternInPlace - mortal
> 	PyString_InternImmortal - immortal
>
> My version favors backward compatibility - existing modules will
> not break if they rely on the immortality of interned strings.
>
> Your version appears to maximize the benefit of interned strings
> - existing modules automatically get the new mortal semantics without
> requiring any changes.
>
> I was wondering what was the rationale behind this decision.

My guess is that it was so existing modules automatically get the benefit of
mortal semantics without requiring any changes <wink> -- coupled with that
nobody believes any module outside the core relies on immortality (Jack's
Mac support code is part of the core, and Jack knows that).

> If the only reason was that the name PyString_Intern is not descriptive
> enough it can be renamed to something like PyString_InternReference to
> make it clear that it operates on a reference to a string and modifies
> it "in place".

If that's all there were to it, I expect Guido would have renamed
PyString_Intern to PyString_InternMortal (a "reference" suffix still doesn't
mean anything to me -- and you've explained it twice <wink>).

If we're wrong that extension modules don't rely on immortality, the alpha
and beta releases should shake that out for all major extensions, including
any that work their way under the PBF umbrella.