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! :-( _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
