<div dir="ltr"><div>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. <br><br>In the table at the bottom of my patch description, it's described as follows:<br><br>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.<br><br>Further, in the code, the comments describe it as follows:<br><br>/* Homogeneous compare: safe for any two compareable objects of the same type. <br>  * (compare_funcs.key_richcompare is set to ob_type->tp_richcompare in the <br>  * pre-sort check.) <br>  */<br><br></div><div>Does that answer your question?<br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 9, 2017 at 6:18 PM Erik <<a href="mailto:python@lucidity.plus.com">python@lucidity.plus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br class="gmail_msg">
<br class="gmail_msg">
I may be way off-base here, but having scanned the patch I'm not sure I<br class="gmail_msg">
agree that it's the right way forward.<br class="gmail_msg">
<br class="gmail_msg">
What seems to be happening is that the homogeneity of the list is<br class="gmail_msg">
determined somehow (whether tracked with a hint or scanned just-in-time)<br class="gmail_msg">
and then a specific comparison function for a known subset of built-in<br class="gmail_msg">
types is selected if appropriate.<br class="gmail_msg">
<br class="gmail_msg">
I had assumed that there would be an "apples-to-apples" comparison<br class="gmail_msg">
function in the type structure and that the patch was simply tracking<br class="gmail_msg">
the list's homogeneity in order to enter a (generic) alternative loop to<br class="gmail_msg">
call that function over PyObject_RichCompare().<br class="gmail_msg">
<br class="gmail_msg">
Why is that not the case? When a new C-level type is introduced (either<br class="gmail_msg">
a built-in or an extension module), why does the list object's code need<br class="gmail_msg">
to know about it in order to perform this optimisation?<br class="gmail_msg">
<br class="gmail_msg">
Why is there not a "tp_apple2apple" slot in the type structure which<br class="gmail_msg">
higher level functions (including the RichCompare() stuff - the first<br class="gmail_msg">
thing that function does is check the type of the objects anyway) can<br class="gmail_msg">
call if it determines that the two objects have the same type?<br class="gmail_msg">
<br class="gmail_msg">
Such a slot would also speed up "contains", "count", etc (for all<br class="gmail_msg">
classes) with no extra work, and no overhead of tracking or scanning the<br class="gmail_msg">
sequence's homogeneity.<br class="gmail_msg">
<br class="gmail_msg">
E.<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>