This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients christian.heimes, facundobatista, mark.dickinson, rhettinger
Date 2008-01-31.17:43:24
SpamBayes Score 0.017102778
Marked as misclassified No
Message-id <1201801407.0.0.421461232644.issue1979@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2008-01-31 17:43:27mark.dickinsonsetspambayes_score: 0.0171028 -> 0.017102778
recipients: + mark.dickinson, rhettinger, facundobatista, christian.heimes
2008-01-31 17:43:27mark.dickinsonsetspambayes_score: 0.0171028 -> 0.0171028
messageid: <1201801407.0.0.421461232644.issue1979@psf.upfronthosting.co.za>
2008-01-31 17:43:26mark.dickinsonlinkissue1979 messages
2008-01-31 17:43:25mark.dickinsoncreate