[Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

[Rob Cliffe]

On 28/04/2011 15:58, Steven D'Aprano wrote:
> Fundamentally, the problem is that some containers bypass equality 
> tests for identity tests. There may be good reasons for that shortcut, 
> but it leads to problems with *any* object that does not define 
> equality to be reflexive, not just NANs.
I say you have that backwards.  It is a legitimate shortcut, and any 
object that (perversely) doesn't define equality to be reflexive leads 
(unsurprisingly) to problems with it (and with *anything else* that - 
very reasonably - assumes that identity implies equality).

>
> Mark Shannon wrote:
>> Although both NaN == NaN and NaN != NaN could arguably be a "maybe" 
>> value, the all important reflexivity (x == x is True)  is effectively 
>> part of the language.
>> All collections rely on it and Python wouldn't be much use without 
>> dicts, tuples and lists.
>
> Perhaps they shouldn't rely on it. Identity tests are an 
> implementation detail. But in any case, reflexivity is *not* a 
> guarantee of Python. With rich comparisons, you can define __eq__ to 
> do anything you like.
>
And you can write
     True = False
(at least in older versions of Python you could).  No language stops you 
from writing stupid programs.

In fact I would propose that the language should DEFINE the meaning of 
"==" to be True if its operands are identical, and only if they are not 
would it use the comparison operators, thus enforcing reflexivity.  
(Nothing stops you from writing your own non-reflexive __eq__ and 
calling it explicitly, and I think it is right that you should have to 
work harder and be more explicit if you want that behaviour.)

Please, please, can we have a bit of common sense and perspective here.  
No-one (not even a mathematician) except someone from Wonderland would 
seriously want an object not equal to itself.

Regards
Rob Cliffe