Antoine Pitrou <solip...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
