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

[Raymond Hettinger]

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
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20050617/8367e132/attachment.htm