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

[Guido van Rossum]

On Mon, Oct 8, 2012 at 11:14 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> 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?

Sorry, it seems I got this part slightly wrong. Forget interning. The
argument goes the other way: If you *do* compute x and y exactly the
same way, and if they don't return the same object, and if they both
return NaN, the rules for comparing NaN apply, and the values must
compare unequal. So if you compute them exactly the same way but
somehow you do return the same object, that shouldn't suddenly make
them compare 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.

Yes, but that's not the choice Python made, so it's irrelevant.
(Unless you now *do* want to change the language, despite stating
several times that you were just asking for explanations. :-)

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

I spent a week with Bertrand recently. He is prone to exaggeration. :-)

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

No, that's not what I meant -- maybe my turn of phrase "invoking IEEE"
was confusing. The first part is what I meant: "Python cannot have a
rule that x is y implies x == y because that would preclude
implementing float.__eq__ as IEEE 754 equality comparison." The second
half should be: "And we have already (independently from all this)
decided that we want to implement float.__eq__ as IEEE 754 equality
comparison." I'm sure a logician could rearrange the words a bit and
make it look more logical.

-- 
--Guido van Rossum (python.org/~guido)