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

Mark Dickinson dickinsm at gmail.com
Tue Mar 23 18:31:40 CET 2010

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 "", line 1, in  File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in eq  other = convertother(other)  File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in convertother  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

More information about the Python-Dev mailing list