[Python-Dev] Intricacies of calling __eq__

Maciej Fijalkowski fijall at gmail.com
Wed Mar 19 17:27:29 CET 2014


On Wed, Mar 19, 2014 at 8:38 AM, Kevin Modzelewski <kmod at dropbox.com> wrote:
> 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! :-(
>>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
>

we're discussing builtin dicts


More information about the Python-Dev mailing list