[Python-Dev] Intricacies of calling __eq__

[Stephen J. Turnbull]

Kevin Modzelewski writes:

 > I think in this case, though, if we say for the sake of argument
 > that the guaranteed semantics of a dictionary lookup are zero or

I don't understand the point of that argument.  It's simply false that
semantics are guaranteed, and all of the dunders might be user
functions.

 > more calls to __hash__ plus zero or more calls to __eq__, then two
 > back-to-back dictionary lookups wouldn't have any observable
 > differences from doing only one, unless you start to make
 > assumptions about the behavior of the implementation.

That's false.  The inverse is true: you should allow the possibility of
observable differences, unless you make assumptions about the behavior
(implying there are none).

 > To me there seems to be a bit of a gap between seeing a dictionary
 > lookup and knowing the exact sequence of user-functions that get
 > called, far more than for example something like "a < b".

The point here is that we *know* that there may be a user function
(the dunder that implements []) being called, and it is very hard to
determine that that function is pure.

Your example of a caching hash is exactly the kind of impure function
that one would expect, but who knows what might be called -- there
could be a reference to a database on Mars involved (do we have a
vehicle on Mars at the moment? anyway...), which calls a pile of
Twisted code, and has latencies of many seconds.

So Steven is precisely right -- in order to allow this optimization,
it would have to be explicitly allowed.

Like Steven, I have no strong feeling against it, but then, I don't
have a program talking to a deep space vehicle in my near future.
Darn it! :-(