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 mark.dickinson
Recipients congma, mark.dickinson, rhettinger, serhiy.storchaka, tim.peters
Date 2021-04-10.07:52:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1618041152.37.0.439070296881.issue43475@roundup.psfhosted.org>
In-reply-to
Content
> Why not have hash() return the id() like we do for instances of object?

I think that's fine, and IIUC that's what Cong Ma was proposing. It seems like the least invasive potential fix.

In principle I find the idea of making NaN a singleton rather attractive - the performance hit is likely negligible, and it solves a bunch of subtle NaN-related issues. (For example, there's still a proposal to provide an IEEE 754 total_ordering key so that lists of floats can be ordered sanely in the presence of nans, but even if you use that you don't know whether your nans will end up at the start or the end of the list, and you could potentially have nans in both places; fixing a single nan and its sign bit would fix that.) But there are bound to be some people somewhere making use of the NaN payload and sign bit, however inadvisedly, and Serhiy's right that this couldn't be extended to Decimal, where the sign bit and payload of the NaN are mandated by the standard.
History
Date User Action Args
2021-04-10 07:52:32mark.dickinsonsetrecipients: + mark.dickinson, tim.peters, rhettinger, serhiy.storchaka, congma
2021-04-10 07:52:32mark.dickinsonsetmessageid: <1618041152.37.0.439070296881.issue43475@roundup.psfhosted.org>
2021-04-10 07:52:32mark.dickinsonlinkissue43475 messages
2021-04-10 07:52:32mark.dickinsoncreate