On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah <stefan@bytereef.org> wrote:
Mark Dickinson <dickinsm@gmail.com> wrote:
[Stefan]
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:
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
Hmm. It seems to me that deliberately making an __eq__ method between hashable types raise an exception isn't something that should be done lightly, since it can *really* screw up sets and dicts. For example, with your proposal, {9.0, Decimal(x)} would either raise or not, depending on whether Decimal(x) happened to hash equal to 9.0 (if they don't hash equal, then __eq__ will never be called). If the hash is regarded as essentially a black box (which is what it should be for most users) then you can easily end up with code that almost always works, but *very* occasionally and unpredicatably raises an exception.
And I think that an sNaN should really signal by default.
Agreed, notwithstanding the above comments. Though to avoid the problems described above, I think the only way to make this acceptable would be to prevent hashing of signaling nans. (Which the decimal module current does; it also prevents hashing of quiet NaNs, but I can't see any good rationale for that.) Mark