__eq__() inconvenience when subclassing set

[Jess Austin]

On Oct 29, 10:41 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> We know the last test fails because the == logic fails to recognize mySet  
> (on the right side) as a "more specialized" object than frozenset (on the  
> left side), because set and frozenset don't have a common base type  
> (although they share a lot of implementation)
>
> I think the only way would require modifying tp_richcompare of  
> set/frozenset objects, so it is aware of subclasses on the right side.  
> Currently, frozenset() == mySet() effectively ignores the fact that mySet  
> is a subclass of set.

I don't think even that would work.  By the time set_richcompare() is
called (incidentally, it's used for both set and frozenset), it's too
late.  That function is not responsible for calling the subclass's
method.  It does call PyAnySet_Check(), but only to short-circuit
equality and inequality for non-set objects.  I believe that something
higher-level in the interpreter decides to call the right-side type's
method because it's a subclass of the left-side type, but I'm not
familiar enough with the code to know where that happens.  It may be
best not to sully such generalized code with a special case for
this.

I may do some experiments with bytes, str, and unicode, since that
seems to be an analogous case.  There is a basestring type, but at
this point I don't know that it really helps with anything.

cheers,
Jess