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:09 | mark.dickinson | set | spambayes_score: 0.07535 -> 0.075350024 recipients: + mark.dickinson, rhettinger, facundobatista |
| 2008年01月31日 10:06:08 | mark.dickinson | set | spambayes_score: 0.07535 -> 0.07535 messageid: <1201773968.87.0.557769659859.issue1979@psf.upfronthosting.co.za> |
| 2008年01月31日 10:06:07 | mark.dickinson | link | issue1979 messages |
| 2008年01月31日 10:06:06 | mark.dickinson | create | |