Explanation of list reference

[Marko Rauhamaa]

Ben Finney <ben+python at 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