<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 28, 2013 at 12:30 PM, Vernon D. Cole <span dir="ltr"><<a href="mailto:vernondcole@gmail.com" target="_blank">vernondcole@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Darn right it should return False.  Given the principle of least surprise (and my prejudices built up over 40 years as a computer programmer) I would expect that decimal.Decimal data would be stored internally as some form of decimal data, and would store into a database as such.  It would be expected to be in a fixed point format.  Real, on the other hand, I would expect to be stored as an IEEE double precision floating point number, or something like that.  <br>


</div>  I don't care whether a fixed point decimal number might be defined by a mathematician as "real" -- I care whether it can be processed by an FPU, and whether it will loose precision in large financial calculations.<br>


<br></div></blockquote><div> </div><div>For the same reason, I could think that isinstance(Decimal, Rational) 
-> True and issubclass(Rational, Real) -> False. It's more about 
exact vs. non-exact computations which is orthogonal to number 
hierarchy. Maybe there should be some ExactNumber abstract base class 
and some convention that exact shouldn't coerce with non-exact. So 
Decimal + float should raise an exception even if both would be 
subclasses of Real (and Decimal even of Rational). Or maybe it would be 
enough if there were just non-exact variants of Real and Complex since 
non-exactness if just issue of them. <br></div></div></div></div>