On Sat, May 15, 2021 at 12:23 AM Paul Bryan <pbr...@anode.ca> wrote: > > I like the idea of supporting fractions to maintain more precision in > calculations. I wonder if this should fall outside the scope of a standard > library and be implemented in an external library. I'd lean toward inclusion > in stdlib. > > A couple of thoughts, which should result in zero breakage of existing code: > > 1. Mirror `decimal.Decimal`, allowing expression of fraction with something > like `fraction.Fraction(numerator, denominator)`.
That can already be done (btw it's "fractions.Fraction"), although I tend to write it as Fraction(numerator) / denominator, since division of a Fraction and an integer works as expected. > 2. Add a new division operator that yields `fraction.Fraction`. Alternatively: Add a Fraction literal. Like an imaginary literal, this would be attached to one half or the other, so what most humans would think of as a literal is actually two of them. It could be something like: >>> 1F / 3 or >>> 1 / 3F It would work just as well either way, but the stdlib would pick one of them to recommend (and then change the repr of a Fraction to produce this). The downside would be that Fraction code would no longer be buried away in the stdlib - it'd be a mandatory part of the running interpreter. I'm not sure how much impact this would have on startup time. This has been suggested a number of times, and IMO it'd be a far easier path forward than either redefining integer division or creating a new operator. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JCFFFD42KBW52UTW4UZVHIRVYYZU7WQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
