Honestly, I don't think we should let the behaviour of signaling NaNs influence the design decisions much here, beyond that yes, `is_nan(some_decimal_snan)` should return `True` (and not raise). They hardly ever turn up in practice, and unlike regular NaNs, you're unlikely to encounter them by accident. They essentially don't exist for float, and I don't think I've ever seen them actually used with Decimal. If whatever solution is adopted happens to "do the right thing", whatever we decide that actually is, with signaling NaNs, then great, but it doesn't seem like something that should be major criterion.
I'm not alone in my lack of respect for sNaNs. Kahan says (in his lecture notes on IEEE 754): NaNs do not trap (unless they are > “Signaling” SNaNs, which exist mainly for political reasons and are rarely > used) While C doesn't support sNaNs, there's a C standard working group draft document (WG14 Document: N1011) titled "Optional support for Signaling NaNs" that says As IEEE-754 is being revised in the year 200x, there is a strong push to > make Signaling NaNs optional and recommend against them. and goes on to describe some of the portability issues that exist around handling sNaNs; the unpredictability of *when* they signal is a large part of this. (The mentioned "strong push" to make snans optional clearly *didn't* actually lead to a change in either IEEE 754-2008 or IEEE 754-2019, but it's interesting to know that this came up.) Sources: - https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF - http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1011.htm Mark
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PX27WS3AYLLZ6I6KBMVB6PPHH3IWXQUD/ Code of Conduct: http://python.org/psf/codeofconduct/
