Add as_integer_ratio() to int() objects

[rhettinger]

BPO	33073
Nosy	@tim-one, @rhettinger, @mdickinson, @vstinner, @njsmith, @serhiy-storchaka, @eric-wieser, @Shredder13, @lisroach
PRs	bpo-33073: Adding as_integer_ratio to ints. #8750 bpo-33073: Fix-up parenthesis, organization, and NULL check #9297 bpo-33073: Fix compiler warning with a type cast #9300 Post-commit updates for bpo-33073. #9303

^{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 = 'https://github.com/lisroach'
closed_at = <Date 2018-09-14.09:42:49.758>
created_at = <Date 2018-03-13.21:25:05.136>
labels = ['3.8', 'type-feature', 'library']
title = 'Add as_integer_ratio() to int() objects'
updated_at = <Date 2018-10-19.21:46:35.061>
user = 'https://github.com/rhettinger'

bugs.python.org fields:

activity = <Date 2018-10-19.21:46:35.061>
actor = 'vstinner'
assignee = 'lisroach'
closed = True
closed_date = <Date 2018-09-14.09:42:49.758>
closer = 'rhettinger'
components = ['Library (Lib)']
creation = <Date 2018-03-13.21:25:05.136>
creator = 'rhettinger'
dependencies = []
files = []
hgrepos = []
issue_num = 33073
keywords = ['patch']
message_count = 26.0
messages = ['313780', '313781', '313782', '313783', '313784', '313785', '313788', '313791', '313794', '313795', '313877', '313891', '313892', '313896', '313898', '313937', '313939', '321538', '321637', '321719', '321729', '321739', '325328', '325336', '325338', '328064']
nosy_count = 9.0
nosy_names = ['tim.peters', 'rhettinger', 'mark.dickinson', 'vstinner', 'njs', 'serhiy.storchaka', 'Eric.Wieser', 'Nofar Schnider', 'lisroach']
pr_nums = ['8750', '9297', '9300', '9303']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue33073'
versions = ['Python 3.8']

[rhettinger]

Goal: make int() more interoperable with float by making a float/Decimal method also available on ints. This will let mypy treat ints as a subtype of floats.

See: https://mail.python.org/pipermail/python-dev/2018-March/152384.html

Open question: Is this also desired for fractions.Fraction and numbers.Rational?

[tim-one]

Is this also desired for fractions.Fraction and numbers.Rational?

I think so. The idea, e.g., that "it's obvious" for Fraction is no more compelling than that it's even more obvious for ints ;-) Given that it's spreading to ints anyway, there's an opportunity to make it possible for clients to write utterly uniform code for every type whose values can be represented as integer ratios.

I'd also say it's desirable to extend the Fraction constructor, to accept argument(s) of any type(s) that implement as_integer_ratio(). But that should probably be a different issue.

[mdickinson]

On the Fraction constructor, it looks like there's some overlap with the goals of issue bpo-28716 here.

[rhettinger]

it looks like there's some overlap with the goals of issue bpo-28716

Okay, let's focus this issue on just int.as_integer_ratio() so that Nofar can have something small and self contained to work on :-)

[Shredder13]

I'm working on it

[serhiy-storchaka]

Wouldn't be better to add the function as_integer_ration() in the math module (or in more appropriate place)?

def as_integer_ration(x):
    if hasattr(x, 'as_integer_ration'):
        return x.as_integer_ration()
    else:
        return (x.numerator, x.denominator)

The advantage over adding the int method is that it will automatically support other rational numbers like NumPy integers.

[tim-one]

Serhiy, we already went down the path of implementing this as a method. Of course numbers.Rational could define the method as return (self.numerator, self.denominator) for itself and its subclasses. Unless I'm confused, that would "magically" define the method for (at least) ints and Fractions too - but I didn't try it.

[gvanrossum]

Actually numbers.Rational is a virtual base class for int, so it won't automagically appear there.

Adding it to the math module is inferior because for non-rational types (e.g. alternative float implementations) the math module won't have the knowledge about internals to implement it -- and casting to float() would defeat the purpose.

[tim-one]

Thanks, Guido! I figured I was missing something :-)

It looks like numbers.Rational is a "for real" base class of fractions.Fraction, though, so I'm in favor of supplying a default implementation of .as_integer_ratio() in numbers.Rational anyway. That would make a clear statement of intent, and would do the right thing for Fraction instances.

[gvanrossum]

+1.

On Tue, Mar 13, 2018, 16:26 Tim Peters <report@bugs.python.org> wrote:

Tim Peters tim@python.org added the comment:

Thanks, Guido! I figured I was missing something :-)

It looks like numbers.Rational is a "for real" base class of
fractions.Fraction, though, so I'm in favor of supplying a default
implementation of .as_integer_ratio() in numbers.Rational anyway. That
would make a clear statement of intent, and would do the right thing for
Fraction instances.

----------

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue33073\>

---