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/

Reply via email to