[Python-Dev] Re: Alternative implementation of string interning

Oren Tirosh oren-py-d@hishome.net
Wed, 3 Jul 2002 03:06:17 -0400


On Tue, Jul 02, 2002 at 11:07:14PM -0700, Ka-Ping Yee wrote:
> Oren Tirosh wrote:
> > Why not make interned strings a type?  <type 'istr'> could be an
> > un-subclassable subclass of string.  intern would just be an
> > alias for this type.  No two istr instances are equal unless they are
> > identical.  I guess PyString_CheckExact would need to be changed to
> > accept either String or InternedString.
> 
> The possibility of people starting to write code that depended on
> whether strings were 'string' or 'istr', and all the breakage and
> incompatibility that would result, seems much too ugly to contemplate.
> Pass an 'istr' into a routine that expects strings, and it would
> appear to be a string right up until someone tried to == it, whereupon
> all hell would break loose.

I don't understand your assumptions.  What kind of hell?  Are you assuming
that == would be equivalent to 'is' for istrs?  The == operator should work 
exactly the same, just possibly a little faster when comparing two istrs.

> The acid test for subtyping is substitutability: type 'istr' would not
> fulfill the contract of 'string', and neither would 'string' fulfill the
> contract of 'istr'.  

Can you be more specific?  As i see it an istr would be completely compatible 
to str with the exception of being non subclassable.  

It has the additional property that

  (type(s) is istr and type(t) is istr and s == t) implies (s is t).

But that doesn't break anything.

	Oren