On Mon, Mar 12, 2018 at 9:18 PM, Tim Peters <tim.pet...@gmail.com> wrote:

> [Guido]
> > .... as_integer_ratio() seems mostly cute (it has Tim Peters all
> > over it),
> Nope!  I had nothing to do with it.  I would have been -0.5 on adding
> it had I been aware at the time.

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
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

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

Python-Dev mailing list

Reply via email to