Explanation of list reference

[Steven D'Aprano]

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