On Tue., 22 Sep. 2020, 10:25 pm Steven D'Aprano, <steve@pearwood.info> wrote:
On Tue, Sep 22, 2020 at 02:13:46PM +0300, Serhiy Storchaka wrote:
> 22.09.20 12:48, Steven D'Aprano пише:
> > Why does `object` define rich comparison dunders `__lt__` etc?

> Because object.__eq__ and object.__ne__ exist. If you define slot
> tp_richcompare in C, it is exposed as 6 methods __eq__, __ne__, __lt__,
> __le__, __gt__ and __ge__. It is not possible to determine that __lt__()
> always returns NotImplemented without running it.

Ah, thank you Serhiy, I thought it might be something like that.

Presumably back when rich comparisons were added, the choice would have
been:

- add one tp_richcompare slot to support all six methods; or

- add six slots, one for each individual dunder

in which case the first option wastes much less space. Is that
a reasonable understanding of the motive?

Looking at https://www.python.org/dev/peps/pep-0207/ I suspect the possibility of having 6 different slots didn't even come up (or if it did, it wasn't considered seriously enough to be mentioned in the PEP).

Instead, the design was an evolution of the old boolean-only tp_compare slot to allow NumPy to return arrays from array comparison operations.

Cheers,
Nick.