[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


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

> 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 

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.