En Mon, 02 Nov 2009 22:05:42 -0300, Jess Austin <jess.aus...@gmail.com>
escribió:
On Nov 1, 1:13 am, "Gabriel Genellina" <gagsl-...@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
--
http://mail.python.org/mailman/listinfo/python-list
