homepage

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