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.