[Python-Dev] Alternative implementation of interning

[Oren Tirosh]

On Sun, Aug 18, 2002 at 11:15:08PM -0400, Tim Peters wrote:
> [Oren Tirosh]
> > ...
> > The problem is in C extension modules. In C there is an incentive to rely
> > on the immortality of interned strings because it makes the code simpler.
> 
> Are you sure about that?  I haven't seen it.
> 
> > There was an example of this in the Mac import code.
> 
> Code *inside* the core can play any dirty tricks it likes, because we
> guarantee to keep it working as things change across releases.  But, AFAICT,
> we have no evidence that anything outside the core abuses this stuff.

I doubt that whoever wrote that code was thinking "hey, this is part of the
core so I can do this".  More likely he was just following the *documented*
promise that interned string are immortal. There may be extension modules 
outside the core that also rely on this promise.

> > PyString_InternInPlace should probably create immortal interned strings
> > for backward compatibility (and deprecated, of course)
> 
> I still doubt it matters to anything outside the core.

Perhaps I'm being overly cautious about breaking promises.  If both you and 
Guido say it's OK who am I to argue...

> > Maybe PyString_Intern should be renamed to PyString_InternReference to
> > make it more obvious that it modifies the pointer "in place".
> 
> You're talking about a function that doesn't exist now, right (I don't
> recognize the name PyString_Intern, and neither it nor
> PyString_InternReference scream anything obvious to me)?

PyString_Intern is the name of the function in my patch that creates a
mortal interned string. PyString_InternInPlace creates immortal interned
strings for compatibility.

	Oren