<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 30, 2016 at 7:20 PM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 12/30/2016 03:36 PM, <a href="mailto:jab@math.brown.edu" target="_blank">jab@math.brown.edu</a> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the use cases I described, the objects' members are ordered. So in the unlikely event that two objects hash to the same value but are unequal, the __eq__ call should be cheap, because they probably differ in length or on their first member, and can skip further comparison. After a successful hash lookup of an object that's already in a set or dict, a successful identity check avoids an expensive equality check. Perhaps I misunderstood?<br>
</blockquote>
<br></span>
If you are relying on an identity check for equality then no two FrozenOrderedCollection instances can be equal.  Was that your intention?  It it was, then just hash the instance's id() and you're done.<br></blockquote><div><br></div><div><br></div><div>No, I was talking about the identity check done by a set or dict when doing a lookup to check if the object in a hash bucket is identical to the object being looked up. In that case, there is no need for the set or dict to even call __eq__. Right?</div><div><br></div><div>The FrozenOrderedCollection.__eq__ implementation I sketched out was as intended -- no identity check there.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If that wasn't your intention then, while there can certainly be a few quick checks to rule out equality (such as length) if those match, the expensive full equality check will have to happen. </blockquote><div><br></div><div>I think we're misunderstanding each other, but at the risk of saying the same thing again: Because it's an ordered collection, the equality check for two unequal instances with the same hash value will very likely be able to bail after comparing lengths or the first items. With a good hash function, the odds of two unequal instances both hashing to the same value and having their first N items equal should be vanishingly small, no?</div></div></div></div>