[Tutor] Implementation of list comparison operators

[Peter Otten]

David Rock wrote:

> 
>> On Jan 17, 2019, at 13:40, Peter Otten <__peter__ at web.de> wrote:
>> 
>> David Rock wrote:
>> 
>>> 
>>> Isn’t this a bit artificial, though?  The reason this is False is
>>> because
>>> you explicitly tell it to return False when using equality.  That’s not
>>> the same thing as using __eq__ without overriding it’s behavior
>>> internally.
>> 
>> Sorry, I don't understand that argument. My point wasn't whether it's a
>> good idea to write objects that compare unequal to themselves -- such
>> objects already exist:
>> 
>>>>> nan = float("nan")
>>>>> nan == nan
>> False
>> 
>> I only warned that a list containing such an object does not meet the
>> intuitive expectation that list_a == list_b implies that all items in
>> list_a compare equal to the respective items in list_b.
> 
> It’s certainly a valid warning.  My confusion came from you using an
> arbitrary example of creating a class that breaks the logic in an override
> rather than one that already exists as a concrete example.  To me, your
> class example looked contrived.
> 
> What is it about the float(“nan”) example that makes this break?
> 
> In [5]: nan = float("nan”)
> 
> In [6]: type(nan)
> Out[6]: float
> 
> In [7]: nan == nan
> Out[7]: False
> 
> In [8]: a = 1.1
> 
> In [9]: a ==a
> Out[9]: True
> 
> In [10]: type(a)
> Out[10]: float
> 
> both a and nan are floats, so why does a == a work, but nan == nan
> doesn’t?

It does "work", it's only produces a result you didn't expect ;) 
Python just follows the standard here

https://en.wikipedia.org/wiki/IEEE_754
https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN

Also:

https://stackoverflow.com/questions/10034149/why-is-nan-not-equal-to-nan