real-life identity and "=="

[Greg Weeks]

I like Python enough to feel a constant itch from the one signficant
feature I don't like.  In this note I scratch my itch.

Python integers and lists are computer approximations of real-life
entities.  The correspondence between computer entities and real-life
entities is of immense practical importance.  Yet Python does not have an
operator that corresponds to real-life identity.

In real life, the number 3 does not have an id().  But a shopping list
does!  Shopping lists on different sheets of paper are distinguishable even
if they have the same contents.  Modifying one of them does not modify the
other.  (In contrast, you can't modify the number 3 and still have the
number 3.  Numbers are immutable.)

In general, mutability affects the notion of identity.  A Python operator
implementing real-life identity would examine the id() of mutable objects,
but would ignore the id() of immutable objects.  Mutable objects are
real-life identical iff they have the same id().  Immutable objects are
real-life identical iff their types and contents are real-life identical.

Because "==" is used in sorting, key comparison, and the "in" operator,
"==" is what I'd want to correspond to real-life identity.  Does it?

"==" views class instances as immutable.  This is not what you'd want for
classes like Point, Quaternion, and the like.  But for these classes "=="
may be fixed by redefining __cmp__.  So user-defined types are fine.

Among built-in types, "==" computes real-life identity for all types
*except* lists and dictionaries.  Damn!  That is what makes me itch.

Now, I agree that comparing the *contents* of lists is sometimes useful.
But "==" should not be the way to do it (just as "=" is not the way to copy
contents).

In practice, it doesn't much matter.  But it itches.  So close!


Greg


PS: Java has a similar problem.  For BitSets for example, the equals() and
hashCode() methods erroneously assume immutability.  Again, so close.