Ben Finney <ben+pyt...@benfinney.id.au>: > You should never need to predict the result of an ‘is’ operation. > (More precisely, for *some* cases you can predict it, but for other > cases you can't.)
No problem there. You have to understand "is" well to use it. Referring to "objects in memory" when defininig "is" leads to circular definitions. 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 That's why "is" is not introductory material. The constraints define a relation that coincides with == wherever it is defined. 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 "==". Marko -- https://mail.python.org/mailman/listinfo/python-list
