On Sun, 28 Mar 2010 05:32:46 pm Adam Olsen wrote:
> On Sat, Mar 27, 2010 at 18:27, Robert Kern <robert.kern at gmail.com>
wrote:
> > On 2010-03-27 13:36 , Adam Olsen wrote:
> >> What's the flaw in using isnan()?
> >
> > There are implicit comparisons being done inside
> > list.__contains__() and other such methods. They do not, and should
> > not, know about isnan().
>
> Those methods should raise an exception. Conceptually, NaN should
> contaminate the result and make list.__contains__() return some
> "unsortable", but we don't want to bend the whole language backwards
> just for one obscure feature, especially when we have a much better
> approach most of the time (exceptions).
I disagree -- if I ask:
3.0 in [1.0, 2.0, float('nan'), 3.0]
I should get True, not an exception. Comparing NANs for equality isn't
an error.
+1 on leaving the behaviour alone -- the surprising behaviour people
have pointed out with NANs in lists, dicts and sets occurs more often
in theory than in practice.
--
Steven D'Aprano
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