(original) (raw)

Looks like it snuck into the float type as part of the fractions.Fraction work in https://bugs.python.org/issue1682 . I couldn't find much related discussion; I suspect that the move was primarily for optimization (see https://github.com/python/cpython/commit/3ea7b41b5805c60a05e697211d0bfc14a62a19fb). Decimal.as\_integer\_ratio was added here: https://bugs.python.org/issue25928 .

I do have significant uses of \`float.as\_integer\_ratio\` in my own code, and wouldn't enjoy seeing it being deprecated/ripped out, though I guess I'd cope.

Some on this thread have suggested that things like is\_integer and as\_integer\_ratio should be math module functions. Any suggestions for how that might be made to work? Would we special-case the types we know about, and handle only those (so the math module would end up having to know about the fractions and decimal modules)? Or add a new magic method (e.g., \_\_as\_integer\_ratio\_\_) for each case we want to handle, like we do for math.\_\_floor\_\_, math.\_\_trunc\_\_ and math.\_\_ceil\_\_? Or use some form of single dispatch, so that custom types can register their own handlers? The majority of current math module functions simply convert their arguments to a float, so a naive implementation of math.is\_integer in the same style wouldn't work: it would give incorrect results for a non-integral Decimal instance that ended up getting rounded to an integral value by the float conversion.

Mark