Mark Dickinson added the comment: 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. Added file: http://bugs.python.org/file9340/richcmp_signal.patch __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1979> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
