[Python-Dev] Re: Last call: mortal interned strings
Guido van Rossum
guido@python.org
Tue, 20 Aug 2002 10:21:28 -0400
> 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.
I can only repeat what I said before about this:
"""But the vast majority of C code does *not* depend on this. I'd
rather keep PyString_InternInPlace(), so we don't have to change all
call locations, only the very rare ones that rely on this."""
> 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".
It wasn't that.
--Guido van Rossum (home page: http://www.python.org/~guido/)