[Python-Dev] Intricacies of calling eq (original) (raw)
Kevin Modzelewski kmod at dropbox.com
Wed Mar 19 07:38:53 CET 2014
- Previous message: [Python-Dev] Intricacies of calling __eq__
- Next message: [Python-Dev] Intricacies of calling __eq__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [Python-Dev] Intricacies of calling __eq__
- Next message: [Python-Dev] Intricacies of calling __eq__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]