On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah <stefan@bytereef.org> wrote:
Facundo Batista <facundobatista@gmail.com> wrote:
On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum <guido@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