On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah <ste...@bytereef.org> wrote:
> Facundo Batista <facundobati...@gmail.com> wrote:
>> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum <gu...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
