[Tutor] Implementation of list comparison operators

[David Rock]

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


— 
David Rock
david at graniteweb.com