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

[Vernon D. Cole]

I stand corrected.  In my mind "Real" and "float" were always synonymous.
(Probably a result of over exposure to FORTRAN, or Alzheimer's.)



On Wed, Aug 28, 2013 at 1:25 PM, Draic Kin <drekin at gmail.com> wrote:

>
> 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/63e83390/attachment.html>