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 -- https://mail.python.org/mailman/listinfo/python-list