Did you have specific changes in mind?

While we're still maintaining 2.x and 3.x code in parallel, there's a benefit to not having the versions of decimal.py diverge too much.  Given that the 2.3-compatible code isn't actually broken, I'm not sure that there's really that much to be gained by changing it.

The ugliest part of the current code is probably the post-application of classmethod instead of using a decorator;  I wouldn't object to fixing that.

I do agree with the general principle that the 3.x version of decimal.py doesn't need to stay backwards compatible with Python 2.3.