__eq__() inconvenience when subclassing set

[Gabriel Genellina]

En Mon, 02 Nov 2009 22:05:42 -0300, Jess Austin <jess.austin at gmail.com>  
escribió:
> On Nov 1, 1:13 am, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:

>> Looks like in 3.1 this can be done with bytes+str and viceversa, even  
>> if bytes and str don't have a common ancestor (other than object;  
>> basestring doesn't exist in 3.x):
>> The same example with set+frozenset (the one you're actually interested  
>> in) doesn't work, unfortunately.

> Thanks for this, Gabriel!  There seems to be a difference between the
> two cases, however:
>
>>>> str() == bytes()
> False
>>>> set() == frozenset()
> True
>
> I doubt that either of these invariants is amenable to modification,
> even for purposes of "consistency".  I'm not sure how to resolve this,
> but you've definitely helped me here. Perhaps the test in
> set_richcompare can return NotImplemented in particular cases but not
> in others?  I'll think about this; let me know if you come up with
> anything more.

I think it should return NotImplemented only when the right-hand side  
operand has overriden tp_richcompare. That way, set()==frozenset() would  
still be True. Only when one inherits from set/frozenset AND overrides  
__eq__, set_richcompare should step aside and let the more specific __eq__  
be called (by just returning NotImplemented).

What is your goal when overriding __eq__ for your new set class? It may  
help building a case for this change; a concrete use case is much better  
than an abstract request.

-- 
Gabriel Genellina