intern'ed strings and deepcopy()

["Martin v. Löwis"]

Alexander Schmolck wrote:

>>Notice that Python does *not* (anymore) guarantee
>>
>>type(a) == type(b) == str and b == a 'implies' id(intern(b)) == id(intern(a))
> 
> 
> Huh? Really?
> 
> I thought  ``id(EXP1) == id(EXP2)`` implies ``EXP1 is EXP2`` and that's the
> only difference I can see between the two lines.
> 
> So does this no longer hold true in python 2.3: "The `is' operator compares
> the identity of two objects; the id() function returns an integer representing
> its identity"?

I meant to explain all this inthe paragraph on mortality of interned 
strings. If a is not interned (and no other string of a's equivalence 
class is), then intern(b) might return a newly-interned string (*). Then
its id() is taken, and then the result of the intern call is no longer 
used. So the newly-interned string may become uninterned. Then intern(a) 
is invoked.

In the original example, writing

   intern(b) is intern(a)

requires that the result of intern(b) is preserved atleast until the 
"is" operator is computed, so it is certain that the string won't die.

(*) In this specific example, this doesn't actually happen: intern(b) 
will return b itself, since no other string has been interned yet. So 
there are other references to the interned string (namely, the variable 
b), so intern(a) later returns b. To make my example more correct, I 
should write

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

so that the strings being interned are temporaries themselves. For some
reason, this still doesn't trigger the mortality of the interned string
in 2.3a2, but I haven't investigated why. In any case, there is no 
*guarantee* (anymore) that the id of an interned string stays the same 
over time; one should store the interned string itself, and not its id.

Regards,
Martin