
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.
-- Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6HXL72CE... Code of Conduct: http://python.org/psf/codeofconduct/