bpo-44547: Make Fractions objects instances of typing.SupportsInt

[mdickinson]

This PR adds an __int__ method to fractions.Fraction, so that an isinstance(some_fraction, typing.SupportsInt) check passes.

https://bugs.python.org/issue44547

[serhiy-storchaka]

What if numerator // denominator is an Integral, but not int (for example if numerator and denominator are GMP integers)?

The int constructor implicitly calls index() for the result of __trunc__(), but __int__() should return an exact int.

[mdickinson]

What if numerator // denominator is an Integral, but not int

Aargh; good point. I'll fix, and add a test for that case.

[mdickinson]

I'll fix, and add a test for that case.

Hmm. The fix is easy; the test less so. The most obvious way to test is to actually create a non-int-subclass that implements numbers.Integral, but that takes quite a lot of code.

[serhiy-storchaka]

I think that we can use an int subclass for simple testing:

class I(int):
    def __floordiv__(self, other):
        return I(int(self) // other)

[mdickinson]

I think that we can use an int subclass for simple testing:

Yes, that's probably good enough. Updated.

[serhiy-storchaka]

I think that __trunc__() can return non-Integral (for example a NumPy array), it will be just incompatible with int() constructor.

[mdickinson]

Yes, true. What do you think about just deleting the second line? (Or maybe simply deleting the whole comment.)

[serhiy-storchaka]

Would not be better to use operator.index()?

[mdickinson]

I'm not sure why; int seems more natural here, given that we're implementing __int__, and it seems a little bit more obvious to me that int must return something of type int (compared to __index__). I think it doesn't really matter all that much - anything implementing Integral and returning different results from __int__ and __index__ is asking for trouble.

Also, in numbers.Integral, __int__ is the more fundamental method: __index__ is implemented in terms of __int__ by default.

[serhiy-storchaka]

What is the performance impact of this change on int()?

[mdickinson]

What is the performance impact of this change on int()?

No idea, but I wouldn't expect it to be significant in either direction. I can do some testing, but performance doesn't seem like it ought to be a major concern here.

[mdickinson]

No idea, but I wouldn't expect it to be significant in either direction

Hmm; I was wrong. I do see a significant difference in casual timings, apparently arising from the slowness of the 'int' call.

On this branch:

lovelace:cpython mdickinson$ ./python.exe -m timeit -s "from fractions import Fraction; f = Fraction(1001, 65)" "int(f)"
2000000 loops, best of 5: 193 nsec per loop

On the main branch:

lovelace:cpython mdickinson$ ./python.exe -m timeit -s "from fractions import Fraction; f = Fraction(1001, 65)" "int(f)"
2000000 loops, best of 5: 166 nsec per loop

Using operator.index is faster here: if I use

    def __int__(a, _index=operator.index):
        """int(a)"""
        if a._numerator < 0:
            return _index(-(-a._numerator // a._denominator))
        else:
            return _index(a._numerator // a._denominator)

I get something that's consistently faster than either of the above:

lovelace:cpython mdickinson$ ./python.exe -m timeit -s "from fractions import Fraction; f = Fraction(1001, 65)" "int(f)"
2000000 loops, best of 5: 156 nsec per loop

[serhiy-storchaka]

Just wondering, what is the performance if remove the index call?

[serhiy-storchaka]

Should this change be backported? If no, it should be documented as a new feature (versionchanged and What's New).

[ambv]

Definitely an enhancement so no backports.