Mark Dickinson <dickinsm@gmail.com> wrote:
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?
It's disallowing all comparisons between e.g. float and decimal. The idea is that the context can provide a cheap way of enforcing types for people who like it:
from decimal import * DefaultContext.strictness = 1 Decimal(9) == 9.0 False Decimal(9) in [1, 4.0 ,9] True
DefaultContext.strictness = 2 Decimal(9) == 9.0 Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in __eq__ other = _convert_other(other) File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in _convert_other raise TypeError("Unable to convert %s to Decimal" % other) TypeError: Unable to convert 9.0 to Decimal Decimal(9) in [1, 4.0 ,9] Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in __eq__ other = _convert_other(other) File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in _convert_other raise TypeError("Unable to convert %s to Decimal" % other) TypeError: Unable to convert 4.0 to Decimal Decimal(9) in [1, 4 ,9] True
This mode could help catch bugs like: n = 7 / 3 # Programmer thinks this is an integer x = Decimal(100) while x != n: pass # do something x -= 1
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.
I'd like to make it an option for people who don't want to write: while x.compare_signal(7) != 0 And I think that an sNaN should really signal by default.
Besides, this seems to me to be an orthogonal issue to the issue of mixing Decimal with other numeric types.
Yes, it would kind of overload the strictness parameter. I see it as another type of strictness, so I brought it up here. Level 3 would be a bit like the highest warning level of a compiler. But of course there's no need to discuss NaNs further in this thread other than to show a possible use of the flag. Stefan Krah