intern'ed strings and deepcopy()

[Martin v. Löwis]

Alexander Schmolck <a.schmolck at gmx.net> writes:

> Well, unless python has a radically different idea from anyone else on what
> interning a string (and "returning *the* interned string" string) means, I'd
> really think that you can rely on:
> 
> >>> type(a) == type(b) == str and b == a and inter(b) is intern(a)

To hold for arbitrary a,b? Certainly not:

>>> a=1
>>> b=2
>>> type(a) == type(b) == str and b == a and inter(b) is intern(a)
False

If you meant that 

type(a) == type(b) == str and b == a 'implies' intern(b) is intern(a)

then yes: Python does guarantee that, for arbitrary a,b.

Notice that Python does *not* (anymore) guarantee

type(a) == type(b) == str and b == a 'implies' id(intern(b)) == id(intern(a))

With Python 2.3, interned strings become mortal, i.e. they may get
uninterned if they are not referred-to anymore (from places other
than the interning dictionary itself).

> I agree the wording there is not particularly clear (and python
> doesn't much encourage "symbolic computation" -- so the intent is
> not to have people write intern("foo") all over the place where a
> lisper would write e.g. :foo), but I'd be really suprised if the
> intern semantics were intended to be unspecified w.r.t. the identity
> property above.

The intention is that intern gives you a unique distinct
representative from the set of equal strings.

Regards,
Martin