Hi.
I may be way off-base here, but having scanned the patch I'm not sure I
agree that it's the right way forward.
What seems to be happening is that the homogeneity of the list is
determined somehow (whether tracked with a hint or scanned just-in-time)
and then a specific comparison function for a known subset of built-in
types is selected if appropriate.
I had assumed that there would be an "apples-to-apples" comparison
function in the type structure and that the patch was simply tracking
the list's homogeneity in order to enter a (generic) alternative loop to
call that function over PyObject_RichCompare().
Why is that not the case? When a new C-level type is introduced (either
a built-in or an extension module), why does the list object's code need
to know about it in order to perform this optimisation?
Why is there not a "tp_apple2apple" slot in the type structure which
higher level functions (including the RichCompare() stuff - the first
thing that function does is check the type of the objects anyway) can
call if it determines that the two objects have the same type?
Such a slot would also speed up "contains", "count", etc (for all
classes) with no extra work, and no overhead of tracking or scanning the
sequence's homogeneity.
E.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
