[Python-Dev] PyObject_RichCompareBool identity shortcut

[Guido van Rossum]

On Thu, Apr 28, 2011 at 3:22 PM, Robert Kern <robert.kern at gmail.com> wrote:
> 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.

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.

-- 
--Guido van Rossum (python.org/~guido)