[issue41598] Adding support for rounding modes to builtin round

Raymond Hettinger added the comment: Given that most of commenters don't think this is a good idea, I'm going to mark it as closed. Feel free to continue the discussion on python-ideas. If it gains traction, open this back up and give it more core-developer attention. -- resolution

[issue41598] Adding support for rounding modes to builtin round

Vedran Čačić added the comment: Well, of course, but that's possible even now, and people still reach for `round`. I guess the problem is that it's too easily accessible. :-) -- ___ Python tracker __

[issue41598] Adding support for rounding modes to builtin round

Eric V. Smith added the comment: If you're using round(str(some_float), digits) and the result is a float, then that's a problem, since you're going to round it again for display at some point. If you want a string result, you're better off using format(float, format_spec), or f-strings, or

[issue41598] Adding support for rounding modes to builtin round

Vedran Čačić added the comment: > Personally, I think I'd rather have easier ways to create Decimal objects Wouldn't everybody? :-P But that's been proposed at least 4 times already and never got anywhere. My proposal is at least original, has a precedent at the above link (strings as surogat

[issue41598] Adding support for rounding modes to builtin round

Mark Dickinson added the comment: @Vedran: > I have tons of these ideas, but usually am afraid of voicing them ... Always good to have ideas brought up, so long as there's no expectation that every idea gets implemented. :-) But I think rounding a string is probably another one for the pyth

[issue41598] Adding support for rounding modes to builtin round

Eric V. Smith added the comment: I don't think we should add this. It will often surprise the user. We get enough .1+.2 != .3 reports as it is, and this would be just as problematic. -- nosy: +eric.smith ___ Python tracker

[issue41598] Adding support for rounding modes to builtin round

marco_ocram added the comment: "- What would you expect round(2.675, ndigits=2, mode=ROUND_HALF_UP) to give? I strongly suspect that Marco would expect and want a result of 2.68. But if we follow the existing rules for round, it's going to give 2.67." Yes, that's right. And my second humble i

[issue41598] Adding support for rounding modes to builtin round

Raymond Hettinger added the comment: Like Mark, I'm not convinced this is a good idea. Outside of finance calculations which typically already use decimal, the need for it is somewhat rare. Also, the API doesn't fit neatly with existing the __round__ dunder methods, so the new feature cou

[issue41598] Adding support for rounding modes to builtin round

Vedran Čačić added the comment: > I'd rather add whatever bells and whistles we need (if any) to make it easier > for users who care about this to use Decimal. This made me think. (I have tons of these ideas, but usually am afraid of voicing them unless encouraged by comments such as this one

[issue41598] Adding support for rounding modes to builtin round

Mark Dickinson added the comment: > I don't think that this will be a very difficult feature to implement. Agreed that it shouldn't be hard to implement, if we do the obvious thing (rounding the exact value that the float represents, rather than trying to do some sort of Do What I Mean round

[issue41598] Adding support for rounding modes to builtin round

Steven D'Aprano added the comment: Okay Marco, I'm changing the title to reflect the new API (support for rounding modes rather than new round functions) and pushed the version to 3.10, since 3.9 is in feature freeze (no new features). This will probably need to be discussed on Python-Ideas,