> From: Edward Loper > > Tim Delaney's suggestion [1] seemed pretty reasonable. In particular: > > - Ensure that NaN is a singleton (like True and False). I.e., the > float constructor checks if the float is NaN, and if so returns a > singleton. Did I say that? I know I thought about the possibility of NaN being a singleton subclass of float, but I don't remember posting it ... It would be nice, but I don't think it's overly feasible. > Advantages: > - We have an easy way to test if a variable is nan: "x is NaN" > - nan will work "properly" as a dictionary key This second statement is not correct. Since NaN would always compare non-equal with itself, it most definitely would not work as a dictionary key. My thoughts were that by having NaN as a separate class, it could raise if __hash__ were called i.e. explicitly preventing it from being used as a dictionary key. > The important question is whether this would slow down other > operations. > As for cmp(), my understanding was that it should just return -1 if > two unordered objects are not equal. Nah - negative for <, 0 for ==, positive for >. And an exception if it's non-comparable (it used to be that __cmp__ wasn't allowed to raise an exception, but this restriction was relaxed). Tim Delaney
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