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

Guido van Rossum guido at python.org
Fri Apr 29 00:55:06 CEST 2011

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)

More information about the Python-Dev mailing list