[Python-Dev] PyObject_RichCompareBool identity shortcut

[Robert Kern]

On 4/28/11 11:55 AM, Guido van Rossum wrote:

> On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern<robert.kern at gmail.com>  wrote:
>> Smaller, certainly. But now it's a trilemma. :-)
>>
>> 1. Have just np.float64 and np.complex128 scalars follow the Python float
>> semantics since they subclass Python float and complex, respectively.
>> 2. Have all np.float* and np.complex* scalars follow the Python float
>> semantics.
>> 3. Keep the current IEEE-754 semantics for all float scalar types.
>
> *If* my proposal gets accepted, there will be a blanket rule that no
> matter how exotic an type's __eq__ is defined, self.__eq__(self)
> (i.e., __eq__ called with the same *object* argument) must return True
> if the type's __eq__ is to be considered well-behaved; and Python
> containers may assume (for the purpose of optimizing their own
> comparison operations) that their elements have a well-behaved __eq__.

*If* so, then we would then just have to decide between #2 and #3.

With respect to this proposal, how does that interact with types that do not 
return bools for rich comparisons? For example, numpy arrays return bool arrays 
for comparisons. SQLAlchemy expressions return other SQLAlchemy expressions, 
etc. I realize that by being "not well-behaved" in this respect, we give up our 
rights to be proper elements in sortable, containment-checking containers. But 
in this and your followup message, you seem to be making a stronger statement 
that self.__eq__(self) not returning anything but True would be a bug in all 
contexts.

-- 
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