This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author seberg
Recipients mark.dickinson, seberg, skrah
Date 2013-02-13.15:29:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1360769383.81.0.493875253305.issue7279@psf.upfronthosting.co.za>
In-reply-to
Content
This is closed, and maybe I am missing something. But from a general point of view, why does hashing of NaN not raise an error as it did for decimals, i.e. why was this not resolved exactly the other way around? I am mostly just wondering about this it is not a problem for me.

Hashing NaNs seems dangerous and surprising because it might work in dicts/sets, but normally doesn't. (The only thing for it to work right would be if NaN was a singleton, but that is impossible for subclasses, etc.).

The thing is:

In [16]: s = {float('nan'): 1, float('nan'): 2, float('nan'): 3}
In [17]: s
Out[17]: {nan: 1, nan: 2, nan: 3}

In [18]: s[float('nan')]
KeyError: nan

In [19]: n = float('nan')
In [20]: s = {n: 1, n: 2, n: 3}
In [21]: s
Out[21]: {nan: 3}

This is because `n is n`, and PyObject_RichCompareBool assumes that if `a is b` then `a == b` which is simply wrong for NaNs and also makes comparisons  of iterables including NaNs an impossible business. NaNs have their unavoidable weirdness, but at least for dictionaries/sets it would seem more clear to me if they raised an error.
History
Date User Action Args
2013-02-13 15:29:43sebergsetrecipients: + seberg, mark.dickinson, skrah
2013-02-13 15:29:43sebergsetmessageid: <1360769383.81.0.493875253305.issue7279@psf.upfronthosting.co.za>
2013-02-13 15:29:43seberglinkissue7279 messages
2013-02-13 15:29:43sebergcreate