[Python-Dev] redefining is (original) (raw)

Andrew Koenig ark-mlist at att.net
Fri Mar 19 15:17:50 EST 2004

Andrew Koenig writes: > If I understand the example correctly, every mutable object is also an > identity object, because you can distinguish between two mutable objects by > changing one of them and seeing if the other changes.

Nope, that's not what I mean. Check out http://mail.python.org/pipermail/python-dev/2004-February/042579.html for Martin's explanation, which is probably better than mine, but here's my simple summary:

Identity Objects: Even if all fields were the same, two instances would be considered "different". With Employee objects, if two employees both have the name "John Smith", they're still different.

In which case every mutable object is always an identity object. I did not say that every identity object is mutable. Where is my misunderstanding?

Value Objects: Object identity is not really important for equality. The purpose of these objects is to represent particular values. So long as all fields are equal, we consider two such values equal. So two lists are the same if both have the same contents. Some value objects (like lists) are mutable, in which case the identity MAY be important to distinguish whether the objects will remain equal if one is modified; others (like strings) are immutable, in which case identity becomes an implementation detail (and in some cases like small ints and interned strings, cpython takes advantage of this).

Exactly. When a value object is immutable, identity is an implementation detail. If two value objects have the same value (which I can define more rigorously if needed), they are equivalent, and identity is an implementation detail.

What I'm saying, I think, is that it would be nice to have a comparison similar to "is" that ignores identity when it is an implementation detail but not otherwise.

You demonstrate case 1: > x = ([], []) > y = ([], []) > Here, x and y are immutable objects that happen to have mutable attributes. > Those objects are equal, but not substitutable.

versus case 2: > a = [] > b = [] > x1 = (a, b) > y1 = (a, b) > Now: x1 and y1 are mutually substitutable; x and y are equal but not > mutually substitutable, and x, y, x1, and y1 are all distinct objects. Interesting. The key here is that "mutable" is used two ways... to mean that the "top-level-object" (the tuple in your example) is not mutable and to mean the the entire structure is not mutable. So if I get this right, you are saying that with these objects: >>> v = ([42],) >>> w = v >>> x = (v[0],) >>> y = ([42],) >>> z = ([999],)

Whenever I have used "immutable" in this discussion, I have meant "top-level immutable". So I consider all tuples to be immutable, even though they may refer to mutable objects.

The '==' operator is useful for distinguishing z from all the others.

Yes, for the current values of v, w, x, y, and z.

The 'is' operator is useful because it distinguishes x from v and w (we usually don't care, but it DOES make a difference in memory use).

Yes. It is also potentially dangerous because it distinguishes x from v and w.

But no operator exists to distinguish y from v, w, and x. By your terminology, v, w, and x are "mutually substitutable", but y is not because while it is equal NOW, it might no longer be equal if we modified the list.

Correct.

Whew.... I hadn't realized it was quite so complex. Looking closely at this, I am beginning to fear that there are not merely 3 meaningful forms of equivalence, but far more than that. Of course, the paper that Peter Norvig referred us to earlier (http://www.nhplace.com/kent/PS/EQUAL.html) said exactly that. Well, thanks for clarifying.

There are certainly more than three meaningful forms of equivalence. I claim, however, that these three forms already have special status in the language, because it is implementation-defined whether two occurrences of the same string literal refer to the same object.

More information about the Python-Dev mailing list