On Thu, Oct 15, 2009 at 3:50 PM, Mick Krippendorf <mad.m...@gmx.de> wrote: > Austin Bingham schrieb: > What you seem to imply is that the hash function imposes some kind of > uniqueness constraint on the set which uses it. That's just not the > case, the uniqueness constraint is always the (in-)equality of objects, > and for this you can override __eq__. But then you must also ensure that > x.__eq__(y) --> y.__eq__(x) & x.__hash() == y.__hash__().
Yes, as was pointed out earlier, I was reading too much into the hash function's role. However, given well behaved hash and equality (which would be a great name for a band), I don't see why those functions need to be defined on the object itself, per se. Right now that's the case because hash() only knows how to call obj.__hash__ (etc. for __eq__). I guess a good analog for what I'm thinking about is list.sort(). It's more than happy to take a comparison operator, and in spirit that's exactly what I'm looking for with sets. > Diez' solution is the pythonic way, and BTW, mathematically and > pythonically sound, wheras, if the hash function would really impose > uniqueness: . . . Yes, my gray c++ roots are showing here; you're right that my brain was secretly expecting the "compiler" to take care of things. Your points about set operations are the strongest in this discussion, and I haven't got a great answer. > Python isn't strong on encapsulation, so "extrinsic" functionality is > quite common. I guess that's part of what's frustrating for me on this issue. Python is generally extremely flexible and open, but in this case I feel like I'm being shut out. Oh well...in the end it looks like there are ways to get what I need, if not what I want. Thanks for the input. Austin -- http://mail.python.org/mailman/listinfo/python-list