[Python-Dev] Propose rejection of PEPs 239 and 240 -- a builtin rational type and rational literals

[Guido van Rossum]

Agreed. Rational arithmetic was the default "exact" arithmetic in ABC
and it did not work out as expected.

On 6/17/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
>  
> These PEPs are four years old.  Nothing is intrinsically wrong with them,
> but they have garnered little enthusiasm, discussion, or support, suggesting
> that the original need was somewhat modest.
>  
> In addition, the principal (but not only) use cases for a builtin rational
> type and corresponding rational literal have already been addressed by the
> decimal module (and the expected future integration of decimal literals). 
> From rationale section of the PEPs:
>  
> """
> Rational numbers are useful for exact and unsurprising arithmetic.  They
> give the correct results people have been taught in various math classes. 
> Making the "obvious" non-integer type one with more predictable semantics
> will surprise new programmers less than using floating point numbers. As
> quite a few posts on c.l.py and on tutor at python.org have shown, people often
> get bit by strange semantics of floating point numbers: for example,
> round(0.98, 2) still gives 0.97999999999999998.
> """
>  
> The future direction of the decimal module likely entails literals in the
> form of 123.45d with binary floats continuing to have the form 123.45.  This
> conflicts with the rational literal proposal of having 123.45 interpreted as
> 123 + 45/100.
>  
> There may still be a use for a rational module in the standard library, but
> builtin support is no longer needed or desirable.
>  
> The PEPs also touch on division ambiguities which were largely resolved by
> the acceptance of PEP 238 which introduced the floor division operator and
> from __future__ import division.
>  
> The rational proposal also has an intrinsic weakness shared with Java's
> prior versions of BigDecimal which they found to be unworkable in practice. 
> The weakness was that repeated operations caused the internal number of
> digits to grow beyond reason.  For this reason, the PEP proposes some
> arbitrary level of truncation which conflicts with the goals of having
> "obvious and exact" arithmetic.  The proposed truncation methodology was
> undeveloped and made no proposal for the same fine level of control as its
> counterpart in the decimal module where issues of variable precision,
> multiple contexts, and alternate rounding modes have been fully thought out.
>  
>  
>  
> Raymond
>  
>  
> 
>   
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
> 
> 
> 


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)