fraction.Fraction does not implement __int__.

[mamrhein]

BPO	44547
Nosy	@rhettinger, @mdickinson, @mamrhein, @ambv, @serhiy-storchaka, @MojoVampire
PRs	bpo-44547: Make Fractions objects instances of typing.SupportsInt #27851

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-10-21.22:10:31.682>
created_at = <Date 2021-07-01.19:52:28.462>
labels = ['type-feature', 'library', '3.11']
title = 'fraction.Fraction does not implement __int__.'
updated_at = <Date 2021-10-21.22:10:31.681>
user = 'https://github.com/mamrhein'

bugs.python.org fields:

activity = <Date 2021-10-21.22:10:31.681>
actor = 'lukasz.langa'
assignee = 'none'
closed = True
closed_date = <Date 2021-10-21.22:10:31.682>
closer = 'lukasz.langa'
components = ['Library (Lib)']
creation = <Date 2021-07-01.19:52:28.462>
creator = 'mamrhein'
dependencies = []
files = []
hgrepos = []
issue_num = 44547
keywords = ['patch']
message_count = 15.0
messages = ['396827', '396840', '396847', '396856', '396858', '396861', '396864', '396868', '396876', '397022', '397033', '399958', '400060', '404682', '404683']
nosy_count = 6.0
nosy_names = ['rhettinger', 'mark.dickinson', 'mamrhein', 'lukasz.langa', 'serhiy.storchaka', 'josh.r']
pr_nums = ['27851']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue44547'
versions = ['Python 3.11']

[mamrhein]

While int, float, complex and Decimal implement __int__, Fraction does not. Thus, checking for typing.SupportsInt for fractions fails, although int(<fraction>) succeeds, because Fraction implements __trunc__.
This looks inconsistent.
Easiest fix seems to be: Fraction.__int__ = Fraction.__trunc__

[MojoVampire]

Seems like an equally reasonable solution would be to make class's with __trunc__ but not __int__ automatically generate a __int__ in terms of __trunc__ (similar to __str__ using __repr__ when the latter is defined but not the former). The inconsistency is in both methods existing, but having the equivalence implemented in int() rather than in the type (thereby making SupportsInt behave unexpectedly, even though it's 100% true that obj.__int__() would fail).

[mdickinson]

FWIW, there's some history here: there's a good reason that fractions.Fraction didn't originally implement __int__.

Back in the Bad Old Days, many Python functions that expected an integer would accept anything whose type implemented __int__ instead, and call __int__ to get the required integer. For example:

Python 3.7.10 (default, Jun  1 2021, 23:43:35) 
[Clang 11.0.3 (clang-1103.0.32.62)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal
>>> chr(Decimal("45.67"))
'-'

Effectively, int was being used to mean two different things: (1) this value can be used as an integer, and (2) this value can be truncated to an integer. The solution was to introduce two new dedicated magic methods index and trunc for these two different meanings. See PEP-357 and PEP-3141 for some of the details. So adding int to fractions.Fraction would have made things like chr(Fraction("5/2")) possible, too.

The behaviour above is still present (with a deprecation warning) in Python 3.9, and chr(Decimal("45.67")) has only finally been made a TypeError in Python 3.10.

We may now finally be in a state where ill-advised uses of __int__ in internal functions have all been deprecated and removed, so that it's safe to re-add __int__ methods.

But still, this seems mostly like an issue with the typing library. What is typing.SupportsInt intended to indicate? That an object can be used _as_ an integer, or that an object can be _truncated_ to an integer?