On Mon, Oct 8, 2012 at 6:31 PM, Alexander Belopolsky firstname.lastname@example.org 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.)