[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Explanation of list reference

On Sat, Feb 15, 2014 at 8:31 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Referring to "objects in memory" when defininig "is" leads to circular
> definitions. It think the best way to define the semantics of "is" is
> through constraints:
>   1. if x is y then y ix x
>   2. if x is y and y is z then x is z
>   3. after x = y, x is y

Yes. Yes. Yes.

>   4. if x is y, then x == y


>>> x = float("nan")
>>> x == x

> The constraints define a relation that coincides with == wherever it is
> defined. So why would you ever use "is" instead of "=="? After all, all
> well-defined programs would behave identically after replacing "is" with
> "==". Really, the only reason would be performance; "is" is often faster
> to evaluate than "==".

Because your criteria are one-way. If x is y, then usually x == y, but
plenty of things compare equal that aren't identical.

>>> x = [1,2,3]
>>> y = [1,2,3]
>>> x == y
>>> x.pop()
>>> x == y

Two things may be equal now and not later, or vice versa, but if
they're identical, they will always be (because they're not "two
things" but one thing), and if they're not identical, they will never
be (because they really are two things, and the traditional marriage
ceremony with the "two becoming one" doesn't happen in computing).
Identity and equality are quite different states, and should be tested
for differently.