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