### osdir.com

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

# Explanation of list reference

```On Sat, 15 Feb 2014 11:31:42 +0200, Marko Rauhamaa wrote:

> 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
>
>   4. if x is y, then x == y

Incorrect.

py> x = float('nan')
py> y = x
py> x is y
True
py> x == y
False

> That's why "is" is not introductory material.

No. "is" is not introductory material because it is an attractive
nuisance for beginners. Beginners have a tendency to think that "is" is a
synonym for "equals", as it can be in English. Sometimes it appears to
work:

x = 2
y = x*3 - 4
x is y
=> probably returns True

but in other cases it fails, confusing the beginner.

With the exception of "is None", beginners almost never need "is".

> The constraints define a relation that coincides with == wherever it is
> defined.

It certainly does not.

class Wacky:
def __eq__(self, other):
return random.random() < 0.5

> 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 "==".

Incorrect. "is" is NOT equivalent to ==, the two are not guaranteed to do
the same thing, you CANNOT safely replace "is" with == or visa versa, and
the meaning of the "is" operator is completely different from the meaning
of the == operator.

The "is" operator tests whether the two operands are the same object,
nothing more, nothing less. The == operator tests whether the two
operands compare equal.

--
Steven

```