[Python-ideas] isinstance(Decimal(), Real) -> False?

[Vernon D. Cole]

On Wed, Aug 28, 2013 at 11:53 AM, Oscar Benjamin <oscar.j.benjamin at gmail.com
> wrote:

> On 28 August 2013 11:48, Draic Kin <drekin at gmail.com> wrote:
> > On Wed, Aug 28, 2013 at 12:30 PM, Vernon D. Cole <vernondcole at gmail.com>
> > wrote:
> >>
> >> 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.
> >>   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.
>
> Decimals are effectively stored internally as integers.

That surprises me, a bit, but given the efficiency of modern 64 bit
processors it's not a bad choice.  We've moved on from the day when CPUs
like the Intel 4004 and the IBM 360 expected to do most of their work in
Binary Coded Decimal.


> They won't be
> processed by the FPU which operates on binary floating point types.
>

_Exactly_ my point.


> Also the decimal module has traps for people who want to prevent
> inexact etc. operations.
>
> > 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.
>

That's it.  This is a  "practicality beats purity" issue.  Python types
Real and Complex are not exact because we usually don't need exact.  "Close
enough" is enough.  I know that 3.14159 is not the true value for Pi,  but
it suffices when I am trying to figure out how fast a vehicle will travel
with a given size tire.

Now, consider when I am processing the arguments for an SQL "execute"
method. [*]  How do I prepare the values for the underlying db engine? I
use a long list which includes lots of "elif isinstance(value, <some Python
type>):"

The code for "isinstance(value, Real)" is quite straight forward.

The code for "isinstance(value, decimal.Decimal)" requires 18 lines of
incredibly obscure Python.

I really do need to be able to tell them apart.

I agree that an Exact ABC would be good. The PEP has a reference to
> exact as a superclass of Rational but I guess it's just left over from
> a previous edit:
> http://www.python.org/dev/peps/pep-3141/#numeric-classes
>
>
> Oscar
>
[*] For this example, I am referring to the code in
http://sf.net/projects/adodbapi of which I am the maintainer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130828/b4d9cb47/attachment.html>