A.T.Hofkamp <[EMAIL PROTECTED]> wrote: > I think that again now with the default implementation of the > object.__eq__ and object.__hash__ methods. I believe these methods should > not exist until the programmer explicitly defines them with a suitable > notion of equivalence. > > Anybody have a good argument against that? :-)
It's very common and practical (though not ideologically pure!) to want each instance of a class to "stand for itself", be equal only to itself: this lets me place instances in a set, etc, without fuss. I don't want, in order to get that often-useful behavior, to have to code a lot of boilerplate such as def __hash__(self): return hash(id(self)) and the like -- so, I like the fact that object does it for me. I'd have no objection if there were two "variants" of object (object itself and politically_correct_object), inheriting from each other either way 'round, one of which kept the current practical approach while the other made __hash__ and comparisons abstract. In Python 3000, ordering comparisons will not exist by default (sigh, a modest loss of practicality on the altar of purity -- ah well, saw it coming, ever since complex numbers lost ordering comparisons), but equality and hashing should remain just like now (yay!). Alex -- http://mail.python.org/mailman/listinfo/python-list