[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@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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com