[Python-Dev] Symmetry arguments for API expansion (original) (raw)

Mark Dickinson dickinsm at gmail.com
Tue Mar 13 06:14:42 EDT 2018

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

[Guido] > .... asintegerratio() 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180313/6c7e77b3/attachment.html>

More information about the Python-Dev mailing list