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, rhettinger |
| Date | 2008年01月10日.03:51:14 |
| SpamBayes Score | 0.018579822 |
| Marked as misclassified | No |
| Message-id | <1199937077.11.0.78867968871.issue1682@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Allowing automatic coercion to and from Decimal sounds dangerous and
complicated to me. Mightn't it be safer just to disallow this (at least for
now)?
I think something like trim() (find the closest rational approximation with
denominator bounded by a given integer) would be useful to have as a Rational
method, but probably only for explicit use.
I'm still worried about equality tests: is it possible to give a good reason
why Decimal("2.5") == Rational(5, 2) should return False, while Rational(5, 2)
== 2.5 returns True. Can someone articulate some workable principle that
dictates when an int/float/complex/Rational/Decimal instance compares equal to
some other int/float/complex/Rational/Decimal instance of possibly different
type but the same numerical value? |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年01月10日 03:51:17 | mark.dickinson | set | spambayes_score: 0.0185798 -> 0.018579822 recipients: + mark.dickinson, gvanrossum, rhettinger, facundobatista, jyasskin |
| 2008年01月10日 03:51:17 | mark.dickinson | set | spambayes_score: 0.0185798 -> 0.0185798 messageid: <1199937077.11.0.78867968871.issue1682@psf.upfronthosting.co.za> |
| 2008年01月10日 03:51:15 | mark.dickinson | link | issue1682 messages |
| 2008年01月10日 03:51:14 | mark.dickinson | create | |