<div dir="ltr">Sorry, I definitely didn't mean to imply that this kind of optimization is valid on arbitrary subscript expressions; I thought we had restricted ourselves to talking about builtin dicts.  If we do, I think this becomes a discussion about what subset of the semantics of CPython's builtins are language-specified vs implementation-dependent; my argument is that just because something results in an observable behavioral difference doesn't necessarily mean that it's a change in language semantics, if it's just a change in the implementation-dependent behavior.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 18, 2014 at 9:54 PM, Stephen J. Turnbull <span dir="ltr"><<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Kevin Modzelewski writes:<br>
<br>
 > I think in this case, though, if we say for the sake of argument<br>
 > that the guaranteed semantics of a dictionary lookup are zero or<br>
<br>
</div>I don't understand the point of that argument.  It's simply false that<br>
semantics are guaranteed, and all of the dunders might be user<br>
functions.<br>
<div class=""><br>
 > more calls to __hash__ plus zero or more calls to __eq__, then two<br>
 > back-to-back dictionary lookups wouldn't have any observable<br>
 > differences from doing only one, unless you start to make<br>
 > assumptions about the behavior of the implementation.<br>
<br>
</div>That's false.  The inverse is true: you should allow the possibility of<br>
observable differences, unless you make assumptions about the behavior<br>
(implying there are none).<br>
<div class=""><br>
 > To me there seems to be a bit of a gap between seeing a dictionary<br>
 > lookup and knowing the exact sequence of user-functions that get<br>
 > called, far more than for example something like "a < b".<br>
<br>
</div>The point here is that we *know* that there may be a user function<br>
(the dunder that implements []) being called, and it is very hard to<br>
determine that that function is pure.<br>
<br>
Your example of a caching hash is exactly the kind of impure function<br>
that one would expect, but who knows what might be called -- there<br>
could be a reference to a database on Mars involved (do we have a<br>
vehicle on Mars at the moment? anyway...), which calls a pile of<br>
Twisted code, and has latencies of many seconds.<br>
<br>
So Steven is precisely right -- in order to allow this optimization,<br>
it would have to be explicitly allowed.<br>
<br>
Like Steven, I have no strong feeling against it, but then, I don't<br>
have a program talking to a deep space vehicle in my near future.<br>
Darn it! :-(<br>
<br>
</blockquote></div><br></div>