Old Man Yells At Cloud

[MRAB]

On 2017-09-17 19:59, Chris Angelico wrote:
> On Mon, Sep 18, 2017 at 4:35 AM, Steve D'Aprano
> <steve+python at pearwood.info> wrote:
>>> So why doesn't it return a fractions.Fraction instead? That way, you
>>> still get "one half" instead of zero, but it's guaranteed to be
>>> accurate. And having 1/3 be a literal meaning "one third" would avoid
>>> all the problems of "1/3 + 1/3 + 1/3 != 3/3". What is the
>>> justification for int/int => float and not rational?
>>
>> (1) Guido doesn't like fractions for the built-in maths operators, because of
>> his experience with ABC where quite simple calculations would end up with
>> bloody enormous fractions with millions of digits in both the numerator and
>> denominator, running slower and slower, for a number where the actual precision
>> was maybe three or four decimal places.
> 
> Okay, that's reasonable. A counter-argument is that if you want
> reduced accuracy to improve performance, you can always ask for it (by
> casting to float), but I do see the disadvantage of slow rationals by
> default.
> 
>> (2) Fractions didn't exist in the standard library when true division was
>> introduced.
> 
> Really? When was true division added? I thought the fractions module
> had been there for several 2.x versions.
> 
The fractions module was introduced in Python 2.6.

[snip]