Mark Dickinson added the comment:
Cool! Works for me.
I agree that it's not 100% clear that round(large_decimal) should return an
integer rather
than raising an exception. But, rightly or wrongly, this is what
int(large_decimal) does at
the moment, and it would be surprising to have int and round behave differently
in this
respect. The current behaviour also fits with the way that int(large_float)
and
round(large_float) behave, with a valid integer result returned even if that
integer is
larger than 2**53.
There is of course a problem here that's not present for floats, namely that
someone can
write round(Decimal("1e1000000")) and then wonder why his/her computer takes so
long to give
an answer. I don't really see any way around this, other than perhaps a note
in the docs.
I notice that math.floor(large_float) and math.ceil(large_float) return floats
at the
moment. Is this something that would change under PEP 3141? If not, should
floor(large_decimal) and ceil(large_decimal) return Decimal instances instead
of integers?
One last thing: would it be worth backporting some of this to Python 2.6, just
to avoid
unnecessary divergence of the Decimal code between 2.x and 3.0? I guess the
trunc()
function calls would have to be replaced by calls to the __trunc__
method---would this be a
problem?
Mark
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1623>
__________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
