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 <CANZJz4jSBX6iPZgVvCB7NdY3My8gWWkTXCeKCRDLo6jcCBgkPg@mail.gmail.com>
In-reply-to <1489291970.05.0.293748253475.issue28685@psf.upfronthosting.co.za>
Content
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>
> _______________________________________
>
History
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