__eq__() inconvenience when subclassing set

[Jess Austin]

I'm subclassing set, and redefining __eq__().  I'd appreciate any
relevant advice.

>>> class mySet(set):
...     def __eq__(self, other):
...         print "called mySet.__eq__()!"
...         if isinstance(other, (set, frozenset)):
...             return True
...         return set.__eq__(self, other)
...

I stipulate that this is a weird thing to do, but this is a toy class
to avoid the lengthy definition of the class I actually want to
write.  Now I want the builtin set and frozenset types to use the new
__eq__() with mySet symmetrically.

>>> mySet() == set([1])
called mySet.__eq__()!
True
>>> mySet() == frozenset([1])
called mySet.__eq__()!
True
>>> set([1]) == mySet()
called mySet.__eq__()!
True
>>> frozenset([1]) == mySet()
False

frozenset doesn't use mySet.__eq__() because mySet is not a subclass
of frozenset as it is for set.  I've tried a number of techniques to
mitigate this issue. If I multiple-inherit from both set and
frozenset, I get the instance lay-out conflict error.  I have similar
problems setting mySet.__bases__ directly, and hacking mro() in a
metaclass.  So far nothing has worked.  If it matters, I'm using 2.6,
but I can change versions if it will help.

Should I give up on this, or is there something else I can try?  Keep
in mind, I must redefine __eq__(), and I'd like to be able to compare
instances of the class to both set and frozenset instances.

cheers,
Jess