[Python-Dev] PEP 0484 - the Numeric Tower

M.-A. Lemburg mal at egenix.com
Wed Oct 14 05:44:40 EDT 2015

On 14.10.2015 01:37, Raymond Hettinger wrote:
>> On Oct 13, 2015, at 9:16 AM, Random832 <random832 at fastmail.com> wrote:
>>> ## ----------------
>>> ## Decimal has all of the methods specified by the Real abc, but it should
>>> ## not be registered as a Real because decimals do not interoperate with
>>> ## binary floats (i.e.  Decimal('3.14') + 2.71828 is undefined).  But,
>>> ## abstract reals are expected to interoperate (i.e. R1 + R2 should be
>>> ## expected to work if R1 and R2 are both Reals).
>> Why?
> Q.  Why is Python the way it is?
> A.   Because Guido said so ;-)
> IIRC, the answer is that we were being conservative with possibly unintended operations between types with differing precision and with differing notions of what numbers could be exactly representable.
> We could have (and still could) make the choice to always coerce to decimal (every float is exactly representable in decimal).  Further, any decimal float or binary float could be losslessly coerced to a Fraction, but that probably isn't what you really want most of the time.  I think people who work in decimal usually want to stay there and people who work with binary floating point want to stay there as well (invisible coercions being more likely to cause pain than relieve pain).

I can only underline this. Conversion to decimals or fractions should
not be implicit. People needing these types will know when they need
them and apply the required explicit conversions to fit their use case.

E.g. in accounting you'll likely use decimal, in finance and science
you stick to floats.

>From a theoretical point of view, it would make sense to add coercion
to these types, but not from a practical point of view.

Marc-Andre Lemburg

Professional Python Services directly from the Experts
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Python-Dev mailing list