Thanks for the review, Nikita!

Thanks@Eclips4 for the PR, and@vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

Sorry,@Eclips4 and@vstinner, I could not cleanly backport this to3.12 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 57ad769076201c858a768d81047f6ea44925a33b 3.12

GH-120197 is a backport of this pull request to the3.13 branch.

I merged the change. Thanks@Eclips4!

I don't think that such change deserves to be backported. It's a minor issue.

While@serhiy-storchaka disagrees with the change:#120080 (comment), IMO it makes the code more consistent. With this change,round(),float.__round__() andint.__round__() acceptNone forndigits. It also makeshelp(nt.__round__) nicer. If tomorrow, we decide to reject None, it should be consistent and be rejected in the 3 ways to call "round". But I don't think that we want to reject None, it's convenient and works currently.

Note: I would prefer to have0 as the default value rather thanNone. But well, it's too change to change such detail :-)

Internally,round(obj, None) callsobj.__round__() (0 arguments), whereasround(obj, ndigits) callsobj.__round__(ndigits) (1 argument).

float.__round__()needs to distinguish 0 from no argument. Accepting None is just an implementation detail. I do not think we should add tests for this, because now this becomes a self-official feature.

int.__round__() could have 0 as the default, this would simplify the code.

I do not think we should add tests for this, because now this becomes a self-official feature.

The tests can be decorated with@support.cpython_only.