[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/)