set using alternative hash function?

[Austin Bingham]

On Thu, Oct 15, 2009 at 3:50 PM, Mick Krippendorf <mad.mick at 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