[Python-Dev] redefining is

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