New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Round default argument for "ndigits" #64132
Comments
From the docs for built-in function "round": But, the only way to get an integer from >>> round(3.5)
4
>>> round(3.5, 1)
3.5
>>> round(3.5, 0)
4.0
>>> round(3.5, -1)
0.0
>>> round(3.5, None)
Traceback (most recent call last):
File "<pyshell#6>", line 1, in <module>
round(3.5, None)
TypeError: 'NoneType' object cannot be interpreted as an integer Either the docs are wrong or the behavior is wrong. I think it's easier to fix the former... But also there should be a way to make round return an integer (e.g. passing |
Here is the preliminary patch. After patch: round(1.23, 0) => 1 not 1.0 round(4.67, 0) => 5 not 5.0 |
Please no! Two-argument round should continue to return a float in all cases. The docs should be fixed. |
I don't understand. There's already a way to make round return an integer: don't pass a second argument. |
Okay, here is the patch to fix the doc. |
Thanks. It's inaccurate to say that a float is returned in general, though: for most builtin numeric types, what's returned has the same type as its input. So rounding a Decimal to two places gives a Decimal on output, etc. (That's already explained in the next paragraph.) |
How about just removing the mention of 'defaults to zero', and say something like: "if ndigits is omitted, returns the nearest int to its input" |
If this function were to be written in Python, it would be something like: def round(number, ndigits=0):
... or def round(number, ndigits=None):
... But in C you can forge the signature to whatever you want and parse the arguments accordingly. In Python there's always a way to get the default behavior by passing the default argument, but in C it may not exist (in this case So, I propose the default value being |
Here is the updated doc fix. Anyway, why not round(1.2) -> 1.0 in the first place? Just curious. |
It was the behavior on Python 2.x, but somehow when they changed the rounding method to nearest even number this happened... I think it's too late to change back the return type. |
Do you have any real-world motivating use case for None? Not just theoretical consistency with what a Python version of the function would look like. (I'm not saying we shouldn't consider supporting None as a low priority change, I'm just trying to figure out where you'd ever need it in the real world.) |
Not really. Just consistency: For the same reason
works... To avoid special casing the function call when you already have a variable to hold the argument. |
Right, but None in that case has real world utility, since you might have the the value in a variable. But you are hardly going to hold int-or-not in a variable, especially a variable that is really about the number of places in the float result... |
All this changed as part of PEP-3141. I wasn't watching Python 3 development closely back then, but I think at least part of the motivation was to provide a way to get away from the use of In the case of In the case of |
In case we want to add consistency with None ndigits, here is the patch adding support for None value for ndigits parameter. This one looks like a low-risk addition but since Python 3.4 is in beta phase.... |
The docstring is better than the current doc as it says that the default precision is 0, without calling that the default for ndigits. ''' round(number[, ndigits]) -> number
--- _sentinel = object
def round(number, ndigits=_sentinel):
if ndigits is _sentinel: ... which makes ndigits positional-or-keyword, and almost optional-with-no-default, as _sentinel is close enough to being a default that cannot be passed in. This is a standard idiom. One who was really picky about having no default could use |
New changeset e3cc75b1000b by Steve Dower in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: