[Python-ideas] checking for identity before comparing built-in objects

[Alexander Belopolsky]

On Mon, Oct 8, 2012 at 10:09 PM, Guido van Rossum <guido at python.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.

True.

> 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.

True.

> 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.