On Aug 3, 2006, at 2:34 AM, Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>> -1 on an extra built-in just to save the time for function call
>
> The time isn't the main issue. The main issue
> is that almost all the use cases for round()
> involve doing an int() on it afterwards. At
> least nobody has put forward an argument to
> the contrary yet.
And I bet the main reason why round() in python returns a float is
because it does in C.
And it does in C because C doesn't have arbitrary size integers, so
if round returned integers, round(1e+308) couldn't work. In python,
however, that's no problem, since python does have arbitrarily big
integers.
There's also round(float("inf")), of course, which wouldn't be
defined if the result was an integer, but I don't think rounding
infinity is much of a use case.
And I do think the extension of round to allow the specification of
number of decimal places was a mistake. If you want that, you
probably really mean to do something like round(x * 10**y) instead.
James
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
