Guido, would you like to go forward with this?

IIRC, you had decided that adding as_integer_ratio() to all the relevant concrete classes was the way to go.  We already had the method on floats and Decimals, and then it was added bool and float, so Fraction is the only one missing.  I believe the goal was to get x.as_integer_ratio() to run without type testing on all concrete numeric types that could support it.

Serhiy is proposing to instead add a math.as_integer_ratio() function that would extract the components differently for different types (see issue 37822). If that had been our plan, then it was a mistake to add as_integer_ratio() to int and bool (as they already have numerator and denominator attributes). If you change you mind and want to go with 37822, we should probably rip-out the 3.8 addition to int and bool.

Jeroen is proposing to down yet another path for this (see issue 28716). He wants to add a __ratio__ method to all the classes and access them with an operator.ratio() function.  He thinks this will help the SageMath package.

My recommendation is to stick with the original plan of adding the as_integer_ratio() to all the concrete types.  The only one left to be done is in the Fractions module.  That is pretty easy -- see PR 15212.

There is some question about whether to change numbers.Rational() but that discussion can be left for another day -- concrete classes are allowed to have extra methods that aren't in the abstract classes.   The abstract classes are harder to change because any existing user classes that had registered as Rational would instantly be non-compliant (though the fix is easy).

I would like to get this finished up for 3.8.  It doesn't make sense to me to have as_integer_ratio() for bool, int, float, and Decimal but to have omitted the most obvious case, Fraction.  That defeats the purpose of having parallel APIs.