On May 4, 10:15 am, Paul McGuire <[EMAIL PROTECTED]> wrote: > Just to beat this into the ground, "test for equality" appears to be > implemented as "test for equality of hashes". So if you want to > implement a class for the purposes of set membership, you must > implement a suitable __hash__ method. It is not sufficient to > implement __cmp__ or __eq__, which I assumed "test for equality" would > make use of. Not having a __hash__ method in my original class caused > my initial confusion.
overriding __hash__ (even to raise NotImplementedError) is always wise if you have override __eq__. And of course __hash__ is necessary for using hashtable-based structures (how else could it determine whether objects are equal? compare against every existing element?) Finally, two objects which return the same __hash__ but return False for __eq__ are, of course, unequal. sets/dicts do not simply "test for equality of hashes" > So would you suggest that any class implemented in a general-purpose > class library should implement __hash__, since one cannot anticipate > when a user might want to insert class instances into a set? (It > certainly is not on my current checklist of methods to add to well- > behaved classes.) a class should be only inserted into a set if it is immutable, and thus designed to such. User's might also execute 'del x.attr', so perhaps you should start each method with a series of hasattr() checks... -Mike -- http://mail.python.org/mailman/listinfo/python-list
