Austin Bingham wrote: > That's definitely a workable solution, but it still rubs me the wrong > way. The uniqueness criteria of a set seems, to me, like a property of > the set, whereas the python model forces it onto each set element.
This is a POV, but to to me, the set just deals with a very minimal protocol - hash-value & equality. Whatever you feed it, it has to cope with that. It strikes *me* as odd to ask for something else. The ideal solution would be to have several hash/eq-methods on your object, and somehow make the surroundings decide which to use. But there is no OO-pragma for that. > Another issue I have with the HashWrapper approach is its space > requirements. Logically, what I'm asking to do is switch out a single > function reference (i.e. to point at get_name() rather than hash()), > but in practice I'm forced to instantiate a new object for each of my > set members. On a large set, this could be disastrous. > > Don't get me wrong...your solution is a good one, but it's just not > what I am looking for. It is the only one you have, short of implementing set your own. And then the terms of implementation would be that you pass a hash- and eq-function & create wrapper-objects internally. Diez -- http://mail.python.org/mailman/listinfo/python-list