Explanation of list reference
steve+comp.lang.python at pearwood.info
Sat Feb 15 11:40:43 CET 2014
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
It certainly does not.
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.
More information about the Python-list