[Python-Dev] Intricacies of calling __eq__

[Maciej Fijalkowski]

On Tue, Mar 18, 2014 at 4:21 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote:
>
>> note that this is specifically about dicts, where __eq__ will be
>> called undecided number of times anyway (depending on collisions in
>> hash/buckets which is implementation specific to start with)
>
> Exactly. Using a __eq__ method with side-effects is a good way to find
> out how many collisions your dict has :-)
>
> But specifically with your example,
>
>     if x in d:
>         return d[x]
>
> my sense of this is that it falls into the same conceptual area as the
> identity optimization for checking list or set containment: slightly
> unclean, but justified. Provided d is an actual built-in dict, and it
> hasn't been modified between one call and the next, I think it would be
> okay to optimize the second lookup d[x].
>
> A question: how far away will this optimization apply?
>
>     if x in d:
>         do_this()
>         do_that()
>         do_something_else()
>         spam = d[x]

it depends what those functions do. JIT will inline them and if
they're small, it should work (although a modification of a different
dict is illegal, since aliasing is not proven), but at some point
it'll give up (Note that it'll also give up with a call to C releasing
GIL since some other thread can modify it).