Mark Dickinson added the comment:
> "the subclass provides" doesn't actually imply anything about overriding, I
> think.
Yes, that was the thrust of one of the SO answers. Unfortunately, that
explanation doesn't work for arithmetic operators, though: there an explicit
override is necessary. Here's another example, partly to get away from the
extra complication of __eq__ being its own inverse. After:
class A(object):
def __lt__(self, other): return True
def __gt__(self, other): return False
def __add__(self, other): return 1729
def __radd__(self, other): return 42
class B(A): pass
we get:
>>> A() + B()
1729
>>> A() < B()
False
So the addition is calling the usual __add__ method first (the special
exception in the docs doesn't apply: while B *is* a subclass of A, it doesn't
*override* A's __radd__ method). But the comparison is (surprisingly) calling
the __gt__ method first.
So we've got two different rules being followed: one for arithmetic operators,
and a different one for comparisons.
This isn't a big deal behaviour-wise: I'm certainly not advocating a behaviour
change here. But it would be nice to document it.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22052>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
