<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 10">
<meta name=Originator content="Microsoft Word 10">
<link rel=File-List href="cid:filelist.xml@01C572F6.108CA060">
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {mso-style-parent:"";
        margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:12.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;
        text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline;
        text-underline:single;}
pre
        {margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:10.0pt;
        font-family:"Courier New";
        mso-fareast-font-family:"Times New Roman";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        mso-style-noshow:yes;
        mso-ansi-font-size:10.0pt;
        mso-bidi-font-size:10.0pt;
        font-family:Arial;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:windowtext;}
span.SpellE
        {mso-style-name:"";
        mso-spl-e:yes;}
span.GramE
        {mso-style-name:"";
        mso-gram-e:yes;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;
        mso-header-margin:.5in;
        mso-footer-margin:.5in;
        mso-paper-source:0;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 table.MsoNormalTable
        {mso-style-name:"Table Normal";
        mso-tstyle-rowband-size:0;
        mso-tstyle-colband-size:0;
        mso-style-noshow:yes;
        mso-style-parent:"";
        mso-padding-alt:0in 5.4pt 0in 5.4pt;
        mso-para-margin:0in;
        mso-para-margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:10.0pt;
        font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'>

<div class=Section1><pre><font size=2 face="Courier New"><span
style='font-size:10.0pt'>These PEPs are four years old. <span style='mso-spacerun:yes'>&nbsp;</span>Nothing is intrinsically wrong with them, but they have garnered little enthusiasm, discussion, or support, suggesting that the original need was somewhat modest.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>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). <span style='mso-spacerun:yes'>&nbsp;</span>From rationale section of the PEPs:<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>&#8220;&#8221;&#8221;<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Rational numbers are useful for exact and unsurprising arithmetic.<span style='mso-spacerun:yes'>&nbsp; </span>They give the correct results people have been taught in various math classes.<span style='mso-spacerun:yes'>&nbsp; </span>Making the &quot;obvious&quot; non-integer type one with more predictable semantics will surprise new programmers less than using floating point numbers. As quite a few posts on <span
class=SpellE>c.l.py</span> and on </span></font><st1:PersonName>tutor@python.org</st1:PersonName> have shown, people often get bit by strange semantics of floating point numbers: for example, <span
class=GramE>round(</span>0.98, 2) still gives 0.97999999999999998.<o:p></o:p></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>&#8220;&#8221;&#8221;<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>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. <span style='mso-spacerun:yes'>&nbsp;</span>This conflicts with the rational literal proposal of having 123.45 interpreted as 123 + 45/100.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>There may still be a use for a rational module in the standard library, but builtin support is no longer needed or desirable.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>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.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>The rational proposal also has an intrinsic weakness shared with Java&#8217;s prior versions of <span
class=SpellE>BigDecimal</span> which they found to be unworkable in practice. <span style='mso-spacerun:yes'>&nbsp;</span>The weakness was that repeated operations caused the internal number of digits to grow beyond reason.<span style='mso-spacerun:yes'>&nbsp; </span>For this reason, the PEP proposes some arbitrary level of truncation which conflicts with the goals of having &#8220;obvious and exact&#8221; arithmetic.<span style='mso-spacerun:yes'>&nbsp; </span>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.<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'>Raymond<o:p></o:p></span></font></pre><pre><font
size=2 face="Courier New"><span style='font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>