Vedran Čačić added the comment:
As much as Steven's proposal would give me what I want in Py3.6, I must say I'm
-1 on it. The assumption of every Fraction being reduced to lowest terms is
really an important invariant that provides numerous opportunities for
optimization (look at __eq__ for example, second if). I think it would be very
wrong to have to generalize all the algorithms of Fraction to work correctly
with non-normalized Fractions.
Furthermore, current (normalized) fractions are Rationals, thus belonging to
the Python numeric tower. non-normalized fractions are not. Even if we _would_
someday have non-normalized fractions in stdlib, they would probably need to be
named differently. (Currently Decimals are having an opposite problem: the main
reason why adding decimal literals to Python is hard is because they would
obviously have to be Reals, thus belonging to numeric tower, while current
decimal.Decimals do not belong there.:)
[And mediants can be usefully researched if you stay within |Q, too; some of my
students have done that. Even Wikipedia says (though it doesn't go into
details):
A way around this, where required, is to specify that both rationals are to
be represented as fractions in their lowest terms (with c > 0, d > 0). With
such a restriction, mediant becomes a well-defined binary operation on
rationals.
from fractions import Fraction
def mediant(p:Fraction, q:Fraction):
return Fraction(p.numerator + q.numerator,
p.denominator + q.denominator)
]
Now, can we go back to a tiny three-character addition with no disadvantages at
all (if I'm wrong, please inform me), making Python stdlib a bit better in
catching accidental mistakes?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27832>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
