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 facundobatista, mark.dickinson, rhettinger
Date 2008-01-31.10:06:06
SpamBayes Score 0.075350024
Marked as misclassified No
Message-id <1201773968.87.0.557769659859.issue1979@psf.upfronthosting.co.za>
In-reply-to
Content
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 (see sections 
7.12.14 and section F.3) and by IEEE 754 and its upcoming revision (see 
section 5.11 of the most recent draft, which is linked to from the wikipedia 
page for IEEE 754r).  Even better from a standards-compliance perspective 
would be to have all comparisons except != involving NaNs raise the 
InvalidOperation flag.

The current behavior also breaks something fundamental:  namely, that x < y 
should have the same truth value as y > x.  Python even depends on this for 
reversing comparison operators, which explains, but in my opinion doesn't 
excuse, the following oddity:

>>> 2 < Decimal("NaN")
True
>>> Decimal(2) < Decimal("NaN")
False
History
Date User Action Args
2008-01-31 10:06:09mark.dickinsonsetspambayes_score: 0.07535 -> 0.075350024
recipients: + mark.dickinson, rhettinger, facundobatista
2008-01-31 10:06:08mark.dickinsonsetspambayes_score: 0.07535 -> 0.07535
messageid: <1201773968.87.0.557769659859.issue1979@psf.upfronthosting.co.za>
2008-01-31 10:06:07mark.dickinsonlinkissue1979 messages
2008-01-31 10:06:06mark.dickinsoncreate