I'm warming to this idea.

We already have several round-to-integer functions (but not round-to-an-arbitrary-number-of-decimal-places) available in the math module (under the names floor, ceil and trunc).  This *does* seem to be a common need, and it's easy to get roll-your-own implementations wrong (e.g., check what the implementation in msg145140 does for negative numbers).  I suspect that once we get more people shifting to py3k we're going to get more complaints about round doing round-half-to-even.

Rather than expanding the signature of round, it might be worth considering a new math-module function (with name to be determined) that does round-half-up for floats.  We might later extend it to other types in the same way as is currently done for floor and ceil (with __floor__ and __ceil__ magic methods);  introduction of such magic methods would probably require a PEP though.

At issue: *which* round-half-up function do we want?  The one that rounds halfway cases away from zero (what Wikipedia calls "Round half away from zero"), or the one that rounds halfway cases towards +infinity?  I'm inclined towards the former.  I don't think it's worth implementing both.

I guess we should follow floor / ceil's lead of returning integer output for float input in the case where number of places to round to isn't given (though personally I would have been happier if floor / ceil had continued to return float output for float input, as in Python 2.x).