__eq__() inconvenience when subclassing set
gagsl-py2 at yahoo.com.ar
Tue Nov 3 02:58:25 CET 2009
En Mon, 02 Nov 2009 22:05:42 -0300, Jess Austin <jess.austin at gmail.com>
> 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()
>>>> set() == frozenset()
> 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.
More information about the Python-list