[Python-Dev] Intricacies of calling eq (original) (raw)

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