On Thu, Oct 15, 2009 at 2:23 PM, Diez B. Roggisch <de...@nospam.web.de> wrote: > Austin Bingham wrote: > 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.
But I'm not really asking for anything that changes the paradigm of how things currently work. All I need is the ability to say something like this: s = set(hash_func = lambda x: hash(x.name)) If set could be de-hardcoded from using hash(), nothing else about how it works would have to change. Or am I wrong on that? I see that you mention equality in the protocol, but I don't know why a set would need that if a) hash(x) == hash(y) --> x == y and b) hash function must return a 32 bit value (which I think is the case)...so maybe I misunderstand something. I wonder...does the requirement of using hash() have to do with the low-level implementation of set? That might explain the state of things. > 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. But why force objects to know about all of the wacky contexts in which they might be used? Let objects be objects and hash-functions be hash-functions. If someone wants a set where uniqueness is defined by the number of occurrences of 'a' in an object's name, the object should never have to know that...it should just have a name. In any event, it sounds like set doesn't have any notion of switching out its hash function, and that more or less answers my question. Austin -- http://mail.python.org/mailman/listinfo/python-list