NaN comparisons - Call For Anecdotes

[Steven D'Aprano]

On Wed, 09 Jul 2014 00:57:03 -0400, Terry Reedy wrote:

> On 7/8/2014 8:10 PM, Steven D'Aprano wrote:
> 
>> There's no force of law that requires Python to enforce reflexivity on
>> values where reflexivity does not apply,
> 
> There are laws of logic that make the lack of reflexivity obnoxious when
> putting objects in collections. 

Floating point numbers are not real numbers and do not obey the laws of 
real arithmetic. Once you allow floats, or comparisons between arbitrary 
types, no matter what you do, something is going to break and somebody is 
going to be upset.


> Python evaded the problem, at least for
> some builtins, by contradicting itself and treating nans as equal to
> themselves in the context of collections.

It's not just NANs. It's any non-reflexive type:

py> class AlwaysUnequal:
...     def __eq__(self, other): return False
... 
py> x = AlwaysUnequal()
py> x in [1, 2, x]
True
py> any(x == a for a in [1, 2, x])
False




> In 2.x, 'in' was defined in terms of ==, but
>  >>> nan=float('nan')
>  >>> nl = [nan]
>  >>> nan in nl
> True
> even though nan != the only member of nl.
> 
> In 3.x, 'in' was redefined to include 'is' as well as '=='.

I don't understand this. You've just shown an example from Python 2 where 
'in' uses 'is'. How is that a Python 3 change?


-- 
Steve