[Python-Dev] Mixing float and Decimal -- thread reboot (original) (raw)

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