Mark Dickinson wrote:

On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic <hrvoje.niksic@avl.com> wrote:

The other day I was surprised to learn this:

nan = float('nan')
nan == nan

False

[nan] == [nan]

True                  # also True in tuples, dicts, etc.

That one surprises me a bit too:  I knew we were using
identity-then-equality checks for containment (nan in [nan]), but I
hadn't realised identity-then-equality was also used for the
item-by-item comparisons when comparing two lists.  It's defensible,
though: [nan] == [nan] should presumably produce the same result as
{nan} == {nan}, and the latter is a test that's arguably based on
containment (for sets s and t, s == t if each element of s is in t,
and vice versa).

I don't think any of this should change.  It seems to me that we've
currently got something approaching the best approximation to
consistency and sanity achievable, given the fundamental
incompatibility of (1) nan breaking reflexivity of equality and (2)
containment being based on equality.  That incompatibility is bound to
create inconsistencies somewhere along the line.

Declaring that 'nan == nan' should be True seems attractive in theory,
but I agree that it doesn't really seem like a realistic option in
terms of backwards compatibility and compatibility with other
mainstream languages.

Totally out of my depth, but what if the a NaN object was allowed to compare equal to itself, but different NaN objects still compared unequal?  If NaN was a singleton then the current behavior makes more sense, but since we get a new NaN with each instance creation is there really a good reason why the same NaN can't be equal to itself?