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 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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
