Alexander Belopolsky wrote:
> With the status quo in Python, it may only make sense to store NaNs in
> array.array, but not in a list.
That's a bit extreme. It only gets you into trouble if you reason like this:
>>> a = b = [1, 2, 3, float('nan')]
>>> if a == b:
... for x,y in zip(a,b):
... assert x==y
...
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
AssertionError
But it's perfectly fine to do this:
>>> sum(a)
nan
exactly as expected. Prohibiting NANs from lists is massive overkill for
a small (alleged) problem.
I know thousands of words have been spilled on this, including many by
myself, but I really believe this discussion is mostly bike-shedding.
Given the vehemence of some replies, and the volume of talk, anyone
would think that you could hardly write a line of Python code without
badly tripping over problems caused by NANs. The truth is, I think, that
most people will never see one in real world code, and those who are
least likely to come across them are the most likely to be categorically
against them.
(I grant that Alexander is an exception -- I understand that he does do
a lot of numeric work, and does come across NANs, and still doesn't like
them one bit.)
--
Steven
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4