`int.__round__(None)` is not supported

[JelleZijlstra]

Bug report

Bug description:

The __round__ method on floats accepts None as an explicit argument, but the one on int does not:

>>> (1.0).__round__(None)
1
>>> (1).__round__(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object cannot be interpreted as an integer

This goes against the general principle that any operation that works on a float should also work on an int.

(Note that both round(x) and round(x, None) work on both floats and ints; this issue is entirely about direct calls to .__round__().)

CPython versions tested on:

3.12, CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-120080: Accept None as a valid argument for direct call of the int.__round__ #120088
• [3.13] gh-120080: Accept None as a valid argument for direct call of the int.__round__ (GH-120088) #120197
• gh-120080: Mark test_round_with_none_arg_direct_call as cpython_only #120328

[serhiy-storchaka]

I do not think that there is a bug. The operation that works on a float and on an int is round(x, None), the rest is an implementation detail. You do not expect that int.__add__ works on a float, aren't?

[vstinner]

Fixed by commit: 57ad769. See my rationale for the change: #120088 (comment).

[serhiy-storchaka]

Note that Decimal.__round__ does not accept None. And perhaps many third-party numeric types do not accept it. Implementing this for int.__round__ sends a false signal that this is required. It won't be long before somebody open an issue about Decimal.__round__, and then authors of third-party libraries will be under pressure to implement this unneeded feature in their code. This opened a can of worms, and we do not know what long term consequences will be.

Not everything that can be implemented should be implemented, and I believe that this is such a case.