You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
Activity
serhiy-storchaka commentedon Jun 5, 2024
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 thatint.__add__works on a float, aren't?gh-120080: Accept ``None`` as a valid argument for direct call of the…
pythongh-120080: Accept ``None`` as a valid argument for direct call …
vstinner commentedon Jun 7, 2024
Fixed by commit: 57ad769. See my rationale for the change: #120088 (comment).
serhiy-storchaka commentedon Jun 7, 2024
Note that
Decimal.__round__does not accept None. And perhaps many third-party numeric types do not accept it. Implementing this forint.__round__sends a false signal that this is required. It won't be long before somebody open an issue aboutDecimal.__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.
vstinner commentedon Jun 7, 2024
My motivation to merge the PR was to avoid
<unrepresentable>in the function signature. This marker causes issues. See for example: https://discuss.python.org/t/ac-null-defaults-prevent-correct-signatures-lets-add-inspect-unrepresentable-to-fix-this/30753serhiy-storchaka commentedon Jun 7, 2024
#73536 is the general solution of this problem.
vstinner commentedon Jun 7, 2024
Ok, but this issue is open since 2017 and is not fixed yet.
IMO accepting None is just a harmless way to fix the issue.
serhiy-storchaka commentedon Jun 7, 2024
Few months ago I finally created a draft (#117671). I hope this will be included in 3.14.
pythongh-120080: Mark test as cpython_only
gh-120080: Mark test_round_with_none_arg_direct_call as cpython_only (#…
pythongh-120080: Mark test_round_with_none_arg_direct_call as cpython…
pythongh-120080: Accept ``None`` as a valid argument for direct call …
pythongh-120080: Mark test_round_with_none_arg_direct_call as cpython…
pythongh-120080: Accept ``None`` as a valid argument for direct call …
pythongh-120080: Mark test_round_with_none_arg_direct_call as cpython…