[Python-Dev] Mixing float and Decimal -- thread reboot

Mark Dickinson dickinsm at gmail.com
Tue Mar 23 14:20:03 CET 2010


On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah <stefan at bytereef.org> wrote:
> Facundo Batista <facundobatista at gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum <guido at python.org> wrote:
>>
>> > As a downside, there is the worry that inadvertent mixing of Decimal
>> > and float can compromise the correctness of programs in a way that is
>> > hard to detect. But the anomalies above indicate that not fixing the
>>
>> Decimal already has something that we can use in this case, and fits
>> very nice here: Signals.
>
> I like the simplicity of having a single signal (e.g. CoercionError), but
> a strictness context flag could offer greater control for people who only
> want pure decimal/integer operations.

Sounds worth considering.

> For example:
>
>  strictness 0: completely promiscuous behaviour
>
>  strictness 1: current py3k behaviour
>
>  strictness 2: current py3k behaviour + pure equality comparisons

Can you explain what you mean by "+ pure equality comparisons" here?
If I'm understanding correctly, this is a mode that's *more* strict
than the current py3k behaviour;  what's it disallowing that the
current py3k behaviour allows?

>  strictness 3: current py3k behaviour + pure equality comparisons +
>                disallow NaN equality comparisons [1]

Sorry, no.  I think there are good reasons for the current NaN
equality behaviour:  2.0 really *isn't* a NaN, and Decimal(2) ==
Decimal('nan') should return False rather than raising an exception.
And the decimal module provides compare and compare_signal for those
who want complete standards-backed control here.  Besides, this seems
to me to be an orthogonal issue to the issue of mixing Decimal with
other numeric types.

Mark


More information about the Python-Dev mailing list