On Oct 29, 10:41 pm, "Gabriel Genellina" <gagsl-...@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 -- http://mail.python.org/mailman/listinfo/python-list