homepage

Here's a patch (richcmp_signal.patch) that gives an alternative way of doing things: all 
<, <=, > and >= comparisons involving a NaN raise the InvalidOperation flag (using exactly 
the same semantics as those specified for compare_signal). == and != comparisons always 
return False and True, respectively, just as they do now.
So the post-patch decimal exactly follows IEEE 754(r) on this. I think it makes good sense 
from a user's viewpoint, too: with the default settings, any <, <=, > or >= comparison 
involving a NaN raises a Python exception; this seems like the best outcome for a beginning 
Decimal user, while expert users can choose to use the public compare or compare_signal 
methods instead.
My worries about list membership testing were nonsensical: there's only one reasonable 
behaviour for == and !=, namely the current behavior, which also matches all the standards.
On balance, I think I prefer this approach to the idea of returning False on comparisons 
involving NaNs. The only fly in the ointment is that floats and Decimals behave 
differently in this respect.