RetroSearch Browse

Mon Nov 9 11:42:49 CET 2009 · https://mail.python.org/pipermail/python-dev/2009-November/093943.html

Raymond Hettinger <python at rcn.com> wrote:
> [Stefan Krah]
> >in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
> >questioning the reasons for allowing NaN comparisons with == and !=
> >rather than raising InvalidOperation.
> 
> Do you have any actual use case issues or are these theoretical musings?
> I ask only because a good use case might suggest the best way to adapt
> the standard to the regular python api for equality/inequality operators.

I think my reasoning goes the opposite way:

The current behavior (raising InvalidOperation) of <, <=, >=, > is sensible
and as close to the standard as one can get.  This behavior was not chosen
for the equality/inequality operators because they _might_ be used for other
purposes.

But since Decimal("NaN") == Decimal("NaN") gives False, these non-decimal
use cases don't work:

>>> d = {0:Decimal("NaN")}
>>> Decimal("NaN") in d.values()
False

So, since non-decimal use cases are limited at best, the equality/inequality
operators might as well have the behavior of the other comparison operators,
which is safer for the user.

I can also give a decimal use case where the current behavior is problematic
A variable initialized to a signaling NaN should always cause an exception.

But this doesn't:

salary = Decimal("sNaN")
minimum_wage = 1000
if (salary == minimum_wage):
    print "do stuff"
else:
    print "do other stuff"

Stefan Krah

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-November/093943.html below:

[Python-Dev] decimal.py: == and != comparisons involving NaNs