sameness/identity

[Andy Freeman]

weeks at vitus.scs.agilent.com (Greg Weeks) wrote in message news:<1001876090.367103 at cswreg.cos.agilent.com>...
>     x = 6.02
>     y = 6.02
> 
> Are x and y identical?  They are identical as *numbers* (which I'll call
> conceptual identity) but not as Python *implentations* of numbers (since
> id(x) != id(y)).  Good programming style requires us to think of numbers
> primarily as numbers and not as their implementations.  So we are more
> interested in conceptual identity than in implementation identity.
...

> Why is (conceptual) identity of numbers different from (conceptual)
> identity of bank accounts?  Because bank accounts are mutable.  A bank
> account can have different states at different times.  A number can't.
> 
> So, we've encountered three kinds of identity in this discussion:
> 
>     A.  conceptual identity
>     B.  implementation identity
>     C.  state identity
> 
> In Python, B corresponds to "is".  And to many Python programmers, C
> corresponds to "==".  But that leaves A without an operator.  I'm unable to
> swallow that.  So, I use "==" for A; I never use "is"; and if I need C --
> which hasn't happened yet -- I write a method for it.

The concept of conceptual identity isn't necessarily well defined for
immutable objects.  (The only reasonable definition for mutable objects
is probably a constrained form of implementation identity, something
along the lines of id that never changes, but note the difficulty in
"never".  Two objects whose lives don't overlap may well have the
same id.  The "same" object in different runs may well have different
ids.)

For immutable strings and numbers, value equality is conceptual equality.
(I'd argue that 1.0, 1L, and 1 are value-disjoint, but ....)

However, Python's tuples are arguably different.  A tuple is an association
without a generally agreed-upon composition rule.  In other words, an
integer can be thought of as a sequence of bits, but it also defines
a composition of those bits that has a (mostly) generally-agreed on
"value".  Moreover, a tuple's elements are not "primitive" in any useful
sense.

>From an implementation's point of view, the possible complexity of a tuple's
elements is an important constraint on reasonable implementations of
conceptual equality.  If we want to use a number-like definition, the
implementation will either have a potentially expensive equality operation
or it will have to return "equal" tuples whenever a tuple is constructed
with the "same" arguments.

A weak argument against defining conceptual equality on tuples like that
on integers is that the integer definition doesn't let one use tuples to
represent the concept "these four objects, associated at a specific moment".
(Weeks probably doesn't like that concept or probably thinks that I should
use a class for it, but ....  Note - lists don't work - they're mutable.)

I don't think that there is a "much more correct" definition for
conceptual equality on tuples.  I personally like the "addressed"
based definition, but am sympathetic to the integer-like definition.
(With the address definition, I can construct the integer-like definition,
but the reverse is not possible and doesn't even make sense.)

-andy