[Python-Dev] Intricacies of calling __eq__

[Kevin Modzelewski]

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.


On Tue, Mar 18, 2014 at 9:54 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> 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! :-(
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140318/7fdc594b/attachment.html>