There is an "apple to apple" compare function. It's unsafe_object_compare. If you look at the pre-sort check, you will find that if the list is homogeneous but not of float, int, string, or tuple, it sets compare_funcs.key_richcompare = ob_type->tp_richcompare and sets compare_funcs.key_compare = unsafe_object_compare. The latter is a wrapper for the former, bypassing the type checks in PyObject_RichCompareBool. Examples of benchmarks that use this functionality include the non-latin string and unbounded int benchmarks.
In the table at the bottom of my patch description, it's described as follows: Compare function for general homogeneous lists; just a wrapper for ob_type->tp_richcompare, which is stored by the pre-sort check at compare_funcs.key_richcompare. This yields modest optimization (neighbourhood of 10%), but we generally hope we can do better. Further, in the code, the comments describe it as follows: /* Homogeneous compare: safe for any two compareable objects of the same type. * (compare_funcs.key_richcompare is set to ob_type->tp_richcompare in the * pre-sort check.) */ Does that answer your question? On Thu, Mar 9, 2017 at 6:18 PM Erik <[email protected]> wrote: > 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 [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
