[issue1979] Make Decimal comparisons with NaN less arbitrary

Mark Dickinson added the comment: Closing. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-lis

[issue1979] Make Decimal comparisons with NaN less arbitrary

Facundo Batista added the comment: Thanks Mark! Shall this issue be closed? __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubsc

[issue1979] Make Decimal comparisons with NaN less arbitrary

Mark Dickinson added the comment: Okay: I checked in this change in r60630. The checkin includes comments in the code and an extra paragraph describing this behavior in the documentation. __ Tracker <[EMAIL PROTECTED]> __

[issue1979] Make Decimal comparisons with NaN less arbitrary

Facundo Batista added the comment: I'm +0 regarding this. If this will go in, a comment should explicit all this in the code, as this behaviour doesn't come from Decimal spec or the PEP. Thanks! __ Tracker <[EMAIL PROTECTED]> _

[issue1979] Make Decimal comparisons with NaN less arbitrary

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 != comparis

[issue1979] Make Decimal comparisons with NaN less arbitrary

Changes by Christian Heimes: -- nosy: +tiran priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscri

[issue1979] Make Decimal comparisons with NaN less arbitrary

Mark Dickinson added the comment: Yes, I think it's necessary. Speaking of standards, it's the current behavior which isn't backed by any standard or rationale other than the historical one involving now-defunct 3- way comparisons. The proposed behavior is much closer to that specified by C99

[issue1979] Make Decimal comparisons with NaN less arbitrary

Raymond Hettinger added the comment: ISTM, you're now moving far beyond the spec into territory that isn't covered by tests or standards. Is this necessary? -- nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> _

[issue1979] Make Decimal comparisons with NaN less arbitrary

New submission from Mark Dickinson: For Python 3.0 the decimal module got rich comparisons. Those comparisons have somewhat unconventional behavior with respect to NaNs, as seen below: <, <= and == comparisons involving NaNs always return False, while >, >= and != comparisons always return