JK,
As a general rule, let Python call the "magic" __method__ methods
behind the scenes. So don't call obj.__hash()__ or obj.__len__ or
obj.__le__ just use hash(obj), len(obj) or <=. Of course there are
exceptions, for example when calling the __init__() method of a
supercalass inside the __init__
JKPeck <[EMAIL PROTECTED]> wrote:
> Thanks for the advice. Once assured that __hash__ etc was the right
> route, I found that using hash() instead of object.__hash__() gave me
> stable hash valules. (I am hashing strings that I know to be unique.)
>
> The "no luck" situation was that a set woul
Thanks for the advice. Once assured that __hash__ etc was the right
route, I found that using hash() instead of object.__hash__() gave me
stable hash valules. (I am hashing strings that I know to be unique.)
The "no luck" situation was that a set would accept the same object
multiple times, not
JK,
You are correct to implement __hash__ and __eq__. The problem is how
you implemented them. Usually your __eq__ method should compare the
necessary attributes of the objects for equality. The __hash__ should
return a 32-bit integer. Your best bet is probably to return a hash of
hashes of your a
JKPeck wrote:
> I would like to be able use sets where the set members are objects of a
> class I wrote.
> I want the members to be distinguished by some of the object content,
> but I have not figured out how a set determines whether two (potential)
> elements are identical. I tried implementing
I would like to be able use sets where the set members are objects of a
class I wrote.
I want the members to be distinguished by some of the object content,
but I have not figured out how a set determines whether two (potential)
elements are identical. I tried implementing __eq__ and __ne__ and
__
