On 4/28/11 6:13 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan
wrote: On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum
wrote: Sorry, we'll have to make an exception for those of course. This will somewhat complicate the interpretation of well-behaved, because those are *not* well-behaved as far as containers go (both dict key lookup and list membership are affected) but it is not a bug -- however it is a bug to put these in containers and then use container comparisons on the container.
That's a point in favour of the status quo, though - with the burden of enforcing reflexivity placed on the containers, types are free to make use of rich comparisons to return more than just simple True/False results.
Possibly. Though for types that *do* return True/False, NaN's behavior can still be infuriating.
I hadn't really thought about it that way before this discussion - it is the identity checking behaviour of the builtin containers that lets us sensibly handle cases like sets of NumPy arrays.
But do they? For non-empty arrays, __eq__ will always return something that is considered true,
Actually, numpy.ndarray.__nonzero__() raises an exception. We've decided that there are no good conventions for deciding whether an array should be considered True or False that won't mislead people. It's quite astonishing how many people will just test "if x == y:" or "if x != y:" for a single set of inputs and "confirm" their guess as to the general rule from that. But your point stands, numpy arrays cannot be members of sets or keys of dicts or orderable/"in-able" elements of lists. -- 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