Skip to content

int.__round__(None) is not supported #120080

Closed

Description

@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

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    3.12only security fixes
    3.13only security fixes
    3.14bugs and security fixes
    and removed
    3.12only security fixes
    3.13only security fixes
    on Jun 4, 2024
  2. serhiy-storchaka commented on Jun 5, 2024

    @serhiy-storchaka
    Member

    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?

  3. added a commit that references this issue on Jun 7, 2024
  4. added a commit that references this issue on Jun 7, 2024
  5. vstinner commented on Jun 7, 2024

    @vstinner
    Member

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

  6. serhiy-storchaka commented on Jun 7, 2024

    @serhiy-storchaka
    Member

    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.

  7. vstinner commented on Jun 7, 2024

    @vstinner
    Member

    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/30753

  8. serhiy-storchaka commented on Jun 7, 2024

    @serhiy-storchaka
    Member

    #73536 is the general solution of this problem.

  9. vstinner commented on Jun 7, 2024

    @vstinner
    Member

    #73536 is the general solution of this problem.

    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.

  10. serhiy-storchaka commented on Jun 7, 2024

    @serhiy-storchaka
    Member

    Few months ago I finally created a draft (#117671). I hope this will be included in 3.14.

  11. added a commit that references this issue on Jun 10, 2024
  12. added a commit that references this issue on Jun 11, 2024
  13. added a commit that references this issue on Jun 30, 2024
  14. added 2 commits that reference this issue on Jul 11, 2024
  15. added 2 commits that reference this issue on Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.14bugs and security fixeseasytype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions