[Python-Dev] Intricacies of calling __eq__
Stephen J. Turnbull
stephen at xemacs.org
Wed Mar 19 05:54:09 CET 2014
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! :-(
More information about the Python-Dev
mailing list