Elliot Gorokhovsky added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue28685> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28685> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
