On Mon, Oct 8, 2012 at 10:09 PM, Guido van Rossum firstname.lastname@example.org wrote:
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).
This is an interesting argument, but I don't quite understand it. Are you suggesting that some valid Python implementation may inter NaNs? Wouldn't that require that all NaNs are equal?
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
True, but this logic does not dictate what this values should be.
-- 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).
Except for operator compareQuietUnordered() which is missing in Python. Note that IEEE 754 also defines totalOrder() operation which is more or less lexicographical ordering of bit patterns. A hypothetical language could map its 6 comparisons to totalOrder() and still claim IEEE 754 conformity as long as it implements the other 22 comparison predicates somehow.
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.
Why would it be a bad thing? Isn't this rule what Bertrand Meyer calls one of the pillars of civilization?
It looks like you give a circular argument. Python cannot have a rule that x is y implies x == y because that would preclude implementing float.__eq__ as IEEE 754 equality comparison and we implement float.__eq__ as IEEE 754 equality comparison in order to provide a significant counterexample to x is y implies x == y rule. I am not sure how interning comes into play here, so I must have missed something.