[Python-Dev] PyObject_RichCompareBool identity shortcut

[Robert Kern]

On 4/28/11 6:13 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan<ncoghlan at gmail.com>  wrote:
>> On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum<guido at python.org>  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