> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4