It was a release build -- it would blow up in a debug build.

Now, regarding the fix you propose: I'll benchmark it tomorrow. If the
impact is small, I agree that it would be an elegant fix. If not, however,
perhaps we just have to get rid of unsafe_object_compare entirely? The
common use cases would still work just fine, and maybe we could add a case
for bytes or something to compensate for the loss.

On Sat, Mar 11, 2017 at 9:12 PM Tim Peters <report@bugs.python.org> wrote:

>
> Tim Peters added the comment:
>
> Elliot, did you run the example in a release build or a debug build?  I'm
> wondering why this:
>
>    assert(v->ob_type == w->ob_type &&
>           v->ob_type->tp_richcompare != NULL &&
>           v->ob_type->tp_richcompare == compare_funcs.key_richcompare);
>
> didn't blow up (in `unsafe_object_compare`).
>
> If that does blow up in a debug build, it suggests "a fix":
> unconditionally check whether the tp_richcompare slot is the expected
> value.  If not, use `PyObject_RichCompareBool(v, w, Py_LT)` instead.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28685>
> _______________________________________
>