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 to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 57ad769076201c858a768d81047f6ea44925a33b 3.12

GH-120197 is a backport of this pull request to the 3.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__() and int.__round__() accept None for ndigits. It also makes help(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 have 0 as the default value rather than None. But well, it's too change to change such detail :-)

Internally, round(obj, None) calls obj.__round__() (0 arguments), whereas round(obj, ndigits) calls obj.__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.