[Python-Dev] Intricacies of calling eq (original) (raw)

Maciej Fijalkowski fijall at gmail.com
Tue Mar 18 12:21:05 CET 2014

On Tue, Mar 18, 2014 at 1:18 PM, Steven D'Aprano <steve at pearwood.info> wrote:

On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote:

On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote: >Hi > >I have a question about calling eq in some cases. > >We're thinking about doing an optimization where say: > >if x in d: > return d[x]

if d.contains(x): return d.getitem(x) [Aside: to be pedantic, Python only calls dunder methods on the class, not the instance, in response to operators and other special calls. That is, type(d).contains rather than d.contains, etc. And to be even more pedantic, that's only true for new-style classes.] I do not see any requirement to call x.eq any particular number of times. The implementation of d might always call somekey.eq(x). The concept of sets (and dicts) requires coherent equality comparisons. To what extent does Python the language specify that user-defined classes must be coherent? How much latitude to shoot oneself in the foot should the language allow? What counts as coherent can depend on the types involved. For instance, I consider IEEE-754 Not-A-Numbers to be coherent, albeit weird. Python goes only so far to accomodate NANs: while it allows a NAN to test unequal even to itself (NAN == NAN returns False), containers are allowed to assume that instances are equal to themselves (NAN in {NAN} returns True). This was discussed in great detail a few years ago, and if I recall correctly, the conclusion was that containers can assume that their elements are reflexive (they equal themselves), but equality == cannot make the same assumption and bypass calling eq. >where d is a dict would result in only one dict lookup (the second one >being constant folded away). The question is whether it's ok to do it, >despite the fact that it changes the semantics on how many times >eq is called on x. A eq that has side-effects violates the intended and expected semanitics of eq. Nevertheless, an eq with side-effects is legal Python and may in fact be useful. It's a tricky one... I don't know how I feel about short-cutting normal Python semantics for speed. On the one hand, faster is good. But on the other hand, it makes it harder to reason about code when things go wrong. "Why is my eq method not being called?" -- Steven

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

note that this is specifically about dicts, where eq will be called undecided number of times anyway (depending on collisions in hash/buckets which is implementation specific to start with)

More information about the Python-Dev mailing list