Martin v. Löwis <mar...@v.loewis.de> added the comment: > 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)) 100000000000000327680 py> int(round(324678,-3)) 325000 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4707> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
