This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author elliot.gorokhovsky
Recipients elliot.gorokhovsky, eryksun, mdk, ppperry, serhiy.storchaka, tim.peters, vstinner
Date 2017-03-12.04:28:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
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 <> 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 <>
> <>
> _______________________________________
Date User Action Args
2017-03-12 04:28:44elliot.gorokhovskysetrecipients: + elliot.gorokhovsky, tim.peters, vstinner, serhiy.storchaka, eryksun, ppperry, mdk
2017-03-12 04:28:44elliot.gorokhovskylinkissue28685 messages
2017-03-12 04:28:44elliot.gorokhovskycreate