[Python-Dev] Intricacies of calling __eq__

[Antony Lee]

The docs don't seem to make any guarantee about calling __eq__ or __hash__:

d[key]
Return the item of d with key key. Raises a KeyError if key is not in the
map.

which seems to indicate that this kind of optimization should be fine.

In fact I would very much like messing with the semantics of __eq__ be
discouraged in the docs.  Currently, the docs merely say "The truth of x==y
does not imply that x!=y is false."  Of course, once __eq__ and __ne__ are
separately overridable nothing can be guaranteed but I've seen code where x
== y and x != y do completely different things and that was not pretty.


2014-03-18 21:27 GMT-07:00 Nick Coghlan <ncoghlan at gmail.com>:

> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/antony.lee%40berkeley.edu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140318/e7063768/attachment.html>