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 tim.peters
Recipients congma, mark.dickinson, rhettinger, serhiy.storchaka, tim.peters
Date 2021-04-11.04:55:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1618116950.87.0.676555684184.issue43475@roundup.psfhosted.org>
In-reply-to
Content
I agree hashing a NaN acting like the generic object hash (return rotated address) is a fine workaround, although I'm not convinced it addresses a real-world problem ;-) But why not? It might.

But that's for CPython. I'm loathe to guarantee anything about this in the language itself. If an implementation wants `__contains__()` tests to treat all NaNs as equal instead, or consider them equal only if "is" holds, or never considers them equal, or resolves equality as bitwise representation equality ... all are fine by me. There's no truly compelling case to made for any of them, although "never considers them equal" is least "surprising" given the insane requirement that NaNs never compare equal under IEEE rules, and that Python-the-language doesn't formally support different notions of equality in different contexts.
History
Date User Action Args
2021-04-11 04:55:50tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, serhiy.storchaka, congma
2021-04-11 04:55:50tim.peterssetmessageid: <1618116950.87.0.676555684184.issue43475@roundup.psfhosted.org>
2021-04-11 04:55:50tim.peterslinkissue43475 messages
2021-04-11 04:55:50tim.peterscreate