Two more thoughts in this thread. (1) The "key" idiom is a great pattern but I don't think it would work well to make it a standard language API.
(2) I'm changing my mind about the default hash(). The original default hash() (which would raise TypeError if __eq__ was overridden but __hash__ was not) is actually quite useful in some situations. Basically, simplifying a bit, there are two types of objects: those that represent *values* and those that do not. For value-ish objects, overriding __eq__ is common and then __hash__ needs to be overridden in order to get the proper dict and set behavior. In a sense, __eq__ defines an "equivalence class" in the mathematical sense. But in many applications I've used objects for which object identity is important. Let me construct a hypothetical example: suppose we represent a car and its parts as objects. Let's say each wheel is an object. Each wheel is unique and we don't have equivalency classes for them. However, it would be useful to construct sets of wheels (e.g. the set of wheels currently on my car that have never had a flat tire). Python sets use hashing just like dicts. The original hash() and __eq__ implementation would work exactly right for this purpose, and it seems silly to have to add it to every object type that could possibly be used as a set member (especially since this means that if a third party library creates objects for you that don't implement __hash__ you'd have a hard time of adding it). In short, I agree something's broken, but the fix should not be to remove the default __hash__ and __eq__ altogether. Instead, the default __hash__ should be made smarter (and perhaps the only way to do this is to build the smarts into hash() again). I do agree that __cmp__, __gt__ etc. should be left undefined by default. All of this is Python 3000 only. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
