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:46:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CANZJz4hyYeKndxF7bwsNx8gHpVBhFURapQHaLy713Z0tK3X2cw@mail.gmail.com>
In-reply-to <1489293125.83.0.492750228094.issue28685@psf.upfronthosting.co.za>
Content
Ya, that makes sense... I just don't get why it's faster at all, then!
Because if we add the (v==w) check, and the tp_richcompare check, how is
unsafe_object_compare any different from PyObject_RichComareBool? Is it
that we're saving function calls? (PyObject_RichCompareBool calls
do_richcompare, so it's one extra call IIRC).

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

>
> Tim Peters added the comment:
>
> The impact would be small:  it would add one (or so) pointer-equality
> compare that, in practice, will always say "yup, they're equal".  Dirt
> cheap, and the branch is 100% predictable.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue28685>
> _______________________________________
>
History
Date User Action Args
2017-03-12 04:46:08elliot.gorokhovskysetrecipients: + elliot.gorokhovsky, tim.peters, vstinner, serhiy.storchaka, eryksun, ppperry, mdk
2017-03-12 04:46:08elliot.gorokhovskylinkissue28685 messages
2017-03-12 04:46:07elliot.gorokhovskycreate