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

[Draic Kin]

On Wed, Aug 28, 2013 at 2:06 PM, Vernon D. Cole <vernondcole at gmail.com>wrote:

> 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.
>
> Python types Real and Complex are abstract base classes, they have no
implementation so are neither exact not non-exact, Python types float and
complex are non-exact.


> 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.
>
> Couldn't you tell them apart by isinstance(value, decimal.Decimal) vs.
isinstance(value, float)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130828/4217374f/attachment.html>