This is covered in the docs, where it says it's an artifact of the
current implementation (i.e., that it so happens that a code object only
contains one instance of a given integer literal today).
> I fail to see why copying mutable or immutable objects would make a
> difference in whether you would use shallow (reference) or deep (value)
> copy.
> ...
I wasn't addressing whether deep or shallow copying is a better
implementation, just addressing what behavior the language definition
guarantees. I.e., trying to be careful to distinguish the language from
the current implementation. I agree that value-copying for immutable
objects would be very surprising (& I'm certainly not arguing in favor of
it!), but I'm not sure the reference manual today _guarantees_ that,
e.g., "x is list[i]" will always be true after "x = list[i]" (and
assuming i < len(list)). I do believe the manual implies it if list[i] is
a mutable object, but not sure it guarantees it in all cases if list[i]
is immutable (mine was solely a language-lawyer kinda point ...).
> In python (and Smalltalk for that matter) all copies are shallow. The
> difference between python and smalltalk is that smalltalk treats
> constants (such as numbers) as special that always return the same id,
> no matter where and how often you use (instantiate) it.
Do you prefer one of these behaviors? E.g., is the Smalltalk treatment
of constants useful, divorced from the rest of the differences between
Smalltalk and Python? I'm not trying to argue here, I'm trying to
understand why the distinction might matter to anyone (switching _out_ of
language-lawyer mode <grin>).
faster-than-the-eye-can-follow-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp