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, gvanrossum, jyasskin, mark.dickinson |
| Date | 2008年01月08日.02:30:50 |
| SpamBayes Score | 0.022864427 |
| Marked as misclassified | No |
| Message-id | <1199759453.71.0.975990532657.issue1623@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Some more comments: (1) I don't think I understand the mechanism by which __lt__ and __le__ are supposed to be called. For example, by adding a few print statements it seems that the comparison Decimal(2) > 3 doesn't call __lt__ at any stage. Is this what's expected, or is this unintended? (2) Also on the subject of __le__ and __lt__: if Decimal is going to have rich comparisons (and I guess it is, one way or another :) ) then we might as well get them right for NaNs: IEEE-754(r) says that any comparison involving NaN should return False, with the exception of != which should always return True. With 3-way comparison it wasn't possible to get this right. This would fix Issue 1514428. (Further discussion of this should probably go there---I don't think it should hold up applying this patch...) (3) I'm getting a serious performance hit from this patch: a complete run of test_decimal.py costs me 22.439 seconds (best of 3) with the patch, and 11.604 seconds without. I'm not sure where this is coming from---perhaps it's unavoidable. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月08日 02:30:53 | mark.dickinson | set | spambayes_score: 0.0228644 -> 0.022864427 recipients: + mark.dickinson, gvanrossum, facundobatista, jyasskin |
| 2008年01月08日 02:30:53 | mark.dickinson | set | spambayes_score: 0.0228644 -> 0.0228644 messageid: <1199759453.71.0.975990532657.issue1623@psf.upfronthosting.co.za> |
| 2008年01月08日 02:30:52 | mark.dickinson | link | issue1623 messages |
| 2008年01月08日 02:30:51 | mark.dickinson | create | |