On Mar 5, 2008, at 3:35 AM, Denis S. Otkidach wrote:
> All hash table implementations (including one in Python) work the same > way: first it looks up a list of key-value pairs by hash, and then > iterate through the list to find a needed key by comparing it with "=" > operator. Thus __eq__ method _is_ used to lookup values in > dictionaries. So, this won't work in some cases: > 1) when __eq__ may return False when comparing to identical (but not > the same, since Python always checks with "is" first), > 2) when __eq__ may return True for objects we want to be assumed > different - in some rare cases when they produce the same hash. > > Although both are not our cases (we always return True, and using id() > for hash guarantees they will never clash), I believe your suggestion > to use IdentitySet and IdentityDict is a right direction. I want to establish a "Expression-friendly" token in the source code for sets and dicts such that we can change underlying implementations as needed. We were doing some source code browsing yesterday and it seems to use __cmp__() for the equality check - so we might not need to move to IdentitySet/Dict just yet. My knowledge of hashtables says that two objects with different hash values can still be subject to the equality comparison if they are placed in the same bucket, so we do need to worry about equality comparison in any case. We have filed http://bugs.python.org/issue2235 to deal with __hash__ not being checked along an inheritance hierarchy so at least as far as 2.6, we will be able to make a base class that provides a default __hash__() method, but it seems like Guido in py3k wants __hash__() and __eq__() to always be redefined at the same level. It seems overly rigid to me but I'm not the person to take up an argument about that (any takers ? :) ). It seems like the long term approach here is to get really nice IdentitySet and IdentityDicts going, and this may even be a place I want to start looking into optional, native extensions for performance purposes. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
