On Sat, Feb 15, 2014 at 8:31 PM, Marko Rauhamaa <ma...@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
No.
>>> x = float("nan")
>>> x == x
False
> 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
True
>>> x.pop()
3
>>> x == y
False
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.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
