[issue28716] Fractions instantiation revisited

Jeroen Demeyer added the comment: See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer for a proposal to define a new dunder __ratio__ (instead of as_integer_ratio) for this. -- nosy: +jdemeyer ___

[issue28716] Fractions instantiation revisited

Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28716] Fractions instantiation revisited

Raymond Hettinger added the comment: FYI, adding int.as_integer_ratio() is being taken care in a separate issue: https://bugs.python.org/issue33073 . I've set it aside for a beginning core-dev mentee to work on because it is simple and self-contained. Pretty

[issue28716] Fractions instantiation revisited

Eric Wieser added the comment: > Are you suggesting that _if_ they were to implement `as_integer_ratio` at > some point in the future, then they'd become compatible with `Fraction` Yes, exactly. Conversely, there's little gain in implementing it _until_

[issue28716] Fractions instantiation revisited

Mark Dickinson added the comment: [Eric Wieser] > This would allow the numpy `np.floating` types to take part in `Fraction` > conversion as well, which would be great. I'm confused: as far as I can tell, the NumPy floating-point types don't implement `as_integer_ratio`.

[issue28716] Fractions instantiation revisited

Stefan Behnel added the comment: Just FYI and as further motivation, I reimplemented this dedicated parser for quicktions (in Cython, so the timings and speedups are not comparable). https://github.com/scoder/quicktions/commit/cc034e07325ec492decdb7b1bcca69246cc780fd I

[issue28716] Fractions instantiation revisited

Stefan Behnel added the comment: Not sure if it's relevant for this specific change, but here's a benchmark that you could use for Fractions: issue22458 -- nosy: +scoder ___ Python tracker

[issue28716] Fractions instantiation revisited

Eric Wieser added the comment: > allows Fraction instantiation from duck-typing classes that provide > as_integer_ratio This would allow the numpy `np.floating` types to take part in `Fraction` conversion as well, which would be great. As far as I can tell,

[issue28716] Fractions instantiation revisited

Wolfgang Maier added the comment: No, I don't think the numeric tower ABC should be replaced by duck-typing. One of the very reasons the fractions module exists is that it showcases how to use the numeric tower. If you want a class to be picked up as a Rational it should be registered as

[issue28716] Fractions instantiation revisited

Josh Rosenberg added the comment: Similarly, type checking for int might be replaced with calling operator.index on the input and handling the TypeError; that way, anything that has declared itself logically int-like is handled without explicit type checking at all. --

[issue28716] Fractions instantiation revisited

Josh Rosenberg added the comment: Might it make sense to make instantiation from numbers.Rational duck typing based as well? Just try to get the numerator and denominator attributes, on AttributeError, skip it and move on. Unless there is some concern that a non-Rational type might have both

[issue28716] Fractions instantiation revisited

Wolfgang Maier added the comment: sure, I just happened to have the profiling available since I used it to optimize things. Here's similar microbenchmarks using perf: STRINGS === $ python -m perf timeit -s "from fractions import Fraction" "Fraction('1.23456e-7')" .

[issue28716] Fractions instantiation revisited

Serhiy Storchaka added the comment: Profiling give you only approximate results. In normal execution the effect of your changes can be opposite. Could you please provide benchmarks without using profiling? -- nosy: +serhiy.storchaka ___ Python

[issue28716] Fractions instantiation revisited

Changes by R. David Murray : -- nosy: +mark.dickinson ___ Python tracker ___ ___

[issue28716] Fractions instantiation revisited

New submission from Wolfgang Maier: I've spent a bit of time lately trying to optimize the instantiation of Fractions. This is related to Issue22464, but instead of focusing on constructing Fractions from ints, my attempts revolve around improving instantiation from strings, floats and