Antoine Pitrou <solipsis@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