[issue4707] round() shows undocumented behaviour

[Mark Dickinson]

Mark Dickinson <dickinsm at gmail.com> added the comment:

> [Me]
> > which is a little odd.  It's the correct result, but I can't see how
[Daniel]
> Is it correct?

No. :-) It should be 0, as you say.

> Given that "round(2, 2**31)" throws an OverflowError

I think this is wrong, too.  It should be 2. It's another consequence of 
the code in bltinmodule.c.  The builtin_round function seems 
unnecessarily complicated:  it converts the second argument from a 
Python object to a C int, then converts it back again before calling the 
appropriate __round__ method.  Then the first thing the __round__ method 
typically does for built-in types is to convert to a C int again.  As 
far as I can tell the first two conversions are unnecessary.

Here's an updated version of the patch that does away with the 
unnecessary conversions, along with the UNDEF_NDIGITS hack.  All tests 
still pass, on my machine, and with this patch I get the results I'd 
expect:

>>> round(2, 2**31)
2
>>> round(2, 2**100)
2
>>> round(2, -2**100)
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt
>> round(2, 1-2**31)
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyboardInterrupt

> That should be optimizable for ndigits > number, and perhaps
> log10(number) < k * ndigits (for large ndigits), right? But I don't
> think it's a realworld  usecase, so dropping this idea for 2.6.

Agreed.  I don't think this optimization is worth it.

Added file: http://bugs.python.org/file12415/round_int_int4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4707>
_______________________________________