[Python-Dev] Mixing float and Decimal -- thread reboot

[Mark Dickinson]

On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah <stefan at bytereef.org> wrote:
> Mark Dickinson <dickinsm at 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