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 loewis
Recipients dingo, giampaolo.rodola, jyasskin, loewis, mark.dickinson, rhettinger
Date 2008-12-20.20:41:55
SpamBayes Score 6.88007e-10
Marked as misclassified No
Message-id <>
In-reply-to <>
> When PEP 3141 says something should be Real, that includes both int and
> float as possibilities (since Real is a supertype of Integral), so it's
> consistent with the PEP for round(int, int) to return an int, and I
> agree with Mark that round(25, -1) ought to return an int.

In that case, the doc string should be fixed:

round(number[, ndigits]) -> floating point number

unless "floating point number" is supposed to include type int
(which I would find fairly confusing).

Wrt. this issue: PEP 3141 specified that round() rounds to even
for floats, leaving it explicitly unspecified how ints get rounded.

If the result is to be an int, the implementation must not go
through floats. It's a problem not only in the border cases,
but also for large numbers (which can't get represented correctly
even remotely):

py> int(round(10**20+324678,-3))
py> int(round(324678,-3))
Date User Action Args
2008-12-20 20:41:56loewissetrecipients: + loewis, rhettinger, mark.dickinson, giampaolo.rodola, jyasskin, dingo
2008-12-20 20:41:56loewislinkissue4707 messages
2008-12-20 20:41:55loewiscreate