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

[Stefan Krah]

Mark Dickinson <dickinsm at 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