[Python-Dev] Impoverished compare ... (original) (raw)
Random832 random832 at fastmail.com
Thu Mar 9 20:41:00 EST 2017
- Previous message (by thread): [Python-Dev] Impoverished compare ...
- Next message (by thread): [Python-Dev] Sharing our python articles with python community
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 PyObjectRichCompare. 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 tprichcompare 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.
- Previous message (by thread): [Python-Dev] Impoverished compare ...
- Next message (by thread): [Python-Dev] Sharing our python articles with python community
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]