[Python-Dev] Impoverished compare ...

[Random832]

On Thu, Mar 9, 2017, at 18:43, Erik wrote:
> Hi.
> 
> I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate 
> some pointers as to the basics of how C-level objects are generally 
> compared in Python 3.
> 
> The issue is related to the performance of PyObject_RichCompare. I got 
> to the point where I was trying to work out what was the _alternative_ 
> to RichCompare. If a comparison is not "rich", then what is it? There's 
> a tp_richcompare slot in the type structure, but I haven't noticed 
> anything else obvious for simple comparison (In 2.x days - which I have 
> more experience with - __cmp__ was a thing which now seems to be gone. I 
> understand the Python-level changes with sort(..., key=foo) but I've not 
> looked at the underlying C implementation until now).

In 2.x the C version of __cmp__ was tp_compare (and it existed even in
python 0.9.1, which had neither dunder methods nor tp_richcompare).

I assume that the "rich compare" name was retained in Python 3 for the
same reason that other names like PyLongObject, PyUnicodeObject were
(not PyStringObject, though, presumably because they don't want people
to unintentionally create a bytes-only API as a result of a lazy porting
process). Maybe Python 4000 can alias it to tp_compare (PyIntObject,
PyStringObject) and Python 5000 can get rid of the current names.

It's "rich" because it knows which of the object-level methods (less
than, greater than, etc) is being called, whereas tp_compare/__cmp__ did
not.