Is nan in (nan,) correct?

[Steven D'Aprano]

random832 at fastmail.us wrote:

> It's been brought up on Stack Overflow that the "in" operator (on
> tuples, and by my testing on dict and list, as well as dict lookup) uses
> object identity as a shortcut, and returns true immediately if the
> object being tested *is* an element of the container. However, the
> contains operation does not specify whether object identity or equality
> is to be used. In effect, the built-in container types use a hybrid
> test: "a is b or a == b".
> 
> My question is, is this a *correct* implementation of the operator, or
> are objects "supposed to" use a basis of equality for these tests?

This has been discussed multiple times on the python-dev mailing list, and
each time the conclusion is the same:

Using `is` to optimize the `in` operator is perfectly acceptable for the
vast bulk of values in Python. There are only a few, like floating point
NANs, where `a is b` does not imply `a == b`, and it is acceptable for
container-types like tuple and list to assume reflexivity (that x == x).

Since reflexivity is *almost* universal, and using object identity permits
very substantial optimizations, the core developers agreed that built-in
contain types may assume that `x is y` implies `x == y`. Users of NANs and
other non-reflexive types can subclass or define their own membership
function.


-- 
Steven