This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients ajaksu2, dingo, giampaolo.rodola, jyasskin, loewis, mark.dickinson, rhettinger
Date 2008-12-21.16:14:19
SpamBayes Score 1.79023e-13
Marked as misclassified No
Message-id <>
> [Me]
> > which is a little odd.  It's the correct result, but I can't see how
> 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 

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

> 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.
Date User Action Args
2008-12-21 16:14:21mark.dickinsonsetrecipients: + mark.dickinson, loewis, rhettinger, giampaolo.rodola, ajaksu2, jyasskin, dingo
2008-12-21 16:14:21mark.dickinsonsetmessageid: <>
2008-12-21 16:14:20mark.dickinsonlinkissue4707 messages
2008-12-21 16:14:20mark.dickinsoncreate