On 4/27/11 12:44 PM, Terry Reedy wrote: > On 4/27/2011 10:53 AM, Guido van Rossum wrote: >> Maybe we should just call off the odd NaN comparison behavior? > > Eiffel seems to have survived, though I do not know if it used for numerical > work. I wonder how much code would break and what the scipy folks would think. I suspect most of us would oppose changing it on general backwards-compatibility grounds rather than actually *liking* the current behavior. If the behavior changed with Python floats, we'd have to mull over whether we try to match that behavior with our scalar types (one of which subclasses from float) and our arrays. We would be either incompatible with Python or C, and we'd probably end up choosing Python to diverge from. It would make a mess, honestly. We already have to explain why equality is funky for arrays (arr1 == arr2 is a rich comparison that gives an array, not a bool, so we can't do containment tests for lists of arrays), so NaN is pretty easy to explain afterward. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
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