I'm not sure this is a bug, but I am trying to understand the rationale
for mimicking IEEE 754 for == and != comparisons involving NaNs. The
comment in decimal.py says:

"Note: The Decimal standard doesn't cover rich comparisons for Decimals.
 In particular, the specification is silent on the subject of what
should happen for a comparison involving a NaN."


First, I think rich comparisons are covered with compare_total(), but
indeed that isn't very useful for == and !=. (It might be useful for
sorting a list of decimals.)

The standard compare() function returns NaN for comparisons involving
NaNs. In addition to that it signals for sNaNs. I'm interpreting this as
"the comparison is undefined". So, in terms of decimal return values,
the standard does define NaN comparisons.

The question remains how to translate "undefined" to a Python truth
value. I'd think that the natural thing is to raise an InvalidOperation
exception in the same way it is done for <, <=, >, >=.


This ...

Decimal("NaN") == 9  ==> InvalidOperation
Decimal("sNaN") == 9  ==> InvalidOperation

... is the behavior of compare_signal(). In my opinion this would follow
the principle of least surprise for the user.