RetroSearch Browse

Mon Nov 9 14:21:24 CET 2009 · https://mail.python.org/pipermail/python-dev/2009-November/093953.html

Antoine Pitrou <solipsis at pitrou.net> wrote:
> > I see the point, but Decimal("NaN") does not hash:
> 
> Ok but witness again:
> 
> >>> L = [1, 2, Decimal("NaN"), 3]
> >>> 3 in L
> True
> >>> class H(object):
> ...   def __eq__(self, other): raise ValueError
> ... 
> >>> L = [1, 2, H(), 3]
> >>> 3 in L
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<stdin>", line 2, in __eq__
> ValueError

Yes, but the list is already broken in two ways:

>>> L.sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/decimal.py", line 877, in __lt__
    ans = self._compare_check_nans(other, context)
  File "/usr/lib/python2.7/decimal.py", line 782, in _compare_check_nans
    self)
  File "/usr/lib/python2.7/decimal.py", line 3755, in _raise_error
    raise error(explanation)
decimal.InvalidOperation: comparison involving NaN

>>> Decimal("NaN") in L
False

> (NB: interestingly, float("nan") does hash)

I wonder if it should:

>>> d = {float('nan'): 10, 0: 20}
>>> 0 in d
True
>>> float('nan') in d
False
>>> d[float('nan')]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: nan
>>> 

I guess my point is that NaNs in lists and dicts are broken in so many
ways that it might be good to discourage this use. (And get the added
benefit of safer mathematical behavior for == and !=.)

Stefan Krah

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

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

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