[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

Nick Coghlan ncoghlan at gmail.com
Fri Feb 17 13:42:45 CET 2012


On Fri, Feb 17, 2012 at 9:33 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>> Maybe it's okay to wait a few years on this, until either 128-bit
>> floats are more common or cDecimal becomes the default floating point
>> type? In the mean time for clock freaks we can have a few specialized
>> APIs that return times in nanoseconds as a (long) integer.
>
> I don't think that the default float type does really matter here. If
> I understood correctly, the major issue with Decimal is that Decimal
> is not fully "compatible" with float: Decimal+float raises a
> TypeError.
>
> Can't we improve the compatibility between Decimal and float, e.g. by
> allowing Decimal+float? Decimal (base 10) + float (base 2) may loss
> precision and this issue matters in some use cases. So we still need a
> way to warn the user on loss of precision. We may add a global flag to
> allow Decimal+float and turn it on by default. Developers concerns by
> loss of precision can just turn the flag off at startup. Something
> like what we did in Python 2: allow str+unicode, and only switch to
> unicode when unicode was mature enough and well accepted :-)

Disallowing implicit binary float and Decimal interoperability was a
deliberate design decision in the original Decimal PEP, in large part
to discourage use of binary floats in applications where exact Decimal
values are required. While this has been relaxed slightly to allow the
exact explicit conversion of a binary float value to its full binary
precision Decimal equivalent, the original rationale against implicit
interoperability still seems valid (See
http://www.python.org/dev/peps/pep-0327/#id17).

OTOH, people have long had to cope with the fact that integer+float
interoperability runs the risk of triggering ValueError if the integer
is too large - it seems to me that the signalling behaviour of
implicit promotions from float to Decimal could be adequately
controlled with the Inexact flag on the Decimal context.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list