David Rock wrote:
>
>> 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?
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
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
