[Python-Dev] PyObject_RichCompareBool identity shortcut (original) (raw)

Robert Kern robert.kern at gmail.com
Fri Apr 29 00:22:13 CEST 2011

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

More information about the Python-Dev mailing list