[Python-ideas] checking for identity before comparing built-in objects
Guido van Rossum
guido at python.org
Tue Oct 9 04:09:53 CEST 2012
On Mon, Oct 8, 2012 at 6:31 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> IEEE 754 standard does not help in answering
> the main question in this thread: should (x is y) imply (x == y)? We
> need to formulate a rationale for breaking this implication without a
> reference to IEEE 754 or Tim's interpretation thereof.
Such a rationale exists in my mind. Since floats are immutable, an
implementation may or may not intern certain float values (just as
certain string and int values are interned but others are not).
Therefore, the fact that "x is y" says nothing about whether the
computations that produced x and y had anything to do with each other.
This is not true for mutable objects: if I have two lists, computed
separately, and find they are the same object, the computations that
produced them must have communicated somehow, or the same list was
passed in to each computations. So, since two computations might
return the same object without having followed the same computational
path, in another implementation the exact same computation might not
return the same object, and so the == comparison should produce the
same value in either case -- in particular, if x and y are both NaN,
all 6 comparisons on them should return False (given that in general
comparing two NaNs returns False regardless of the operator used).
The reason for invoking IEEE 754 here is that without it, Python might
well have grown a language-wide rule stating that an object should
*always* compare equal to itself, as there would have been no
significant counterexamples. (As it is, such a rule only exists for
containers, and technically even there it is optional -- it is just
not required for containers to invoke == for contained items that
reference the same object.)
--
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas
mailing list