[Python-Dev] Intricacies of calling __eq__

[Nick Coghlan]

On 19 March 2014 11:09, Steven D'Aprano <steve at pearwood.info> wrote:
> Although I have tentatively said I think this is okay, it is a change in
> actual semantics of Python code: what you write is no longer what gets
> run. That makes this *very* different from changing the implementation
> of sort -- by analogy, its more like changing the semantics of
>
>     a = f(x) + f(x)
>
> to only call f(x) once. I don't think you would call that an
> implementation detail, would you? Even if justified -- f(x) is a pure,
> deterministic function with no side-effects -- it would still be a
> change to the high-level behaviour of the code.

Ah, I think this is a good alternative example. Given the stated
assumptions (true builtin dict, not modified between operations),
would we be OK with PyPI optimising the following to only do a single
dict lookup:

    a = d[x] + d[x]

It's essentially the same optimisation as the one being discussed - in
the code *as written*, there are two lookups visible, but for any
sensible __hash__ and __eq__ implementation, they should always give
the same answer for a true builtin dict that isn't modified between
the two lookups. (and yes, PyPy has the infrastructure to enforce
those constraints safely and fall back to normal execution if they
aren't met - that ability to take opportunistic advantage of known
behaviours of particular types is one of the key things that makes it
such a powerful tool for implicit optimisations, as compared to things
like Cython and Numba, which change semantics more markedly, but also
have to be explicitly applied to specific sections of your code rather
than being applied automatically).

I think it's certainly borderline (it's the kind of surprising
behavioural change that irritates people about C/C++ optimisers), but
I also think it's a defensible optimisation if the gain is significant
enough.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia