> On Jan 17, 2019, at 13:40, Peter Otten <__pete...@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
da...@graniteweb.com
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
