Message223812
| Author |
mark.dickinson |
| Recipients |
docs@python, mark.dickinson, r.david.murray |
| Date |
2014年07月24日.07:19:35 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1406186375.86.0.694825382533.issue22052@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> "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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2014年07月24日 07:19:35 | mark.dickinson | set | recipients:
+ mark.dickinson, r.david.murray, docs@python |
| 2014年07月24日 07:19:35 | mark.dickinson | set | messageid: <1406186375.86.0.694825382533.issue22052@psf.upfronthosting.co.za> |
| 2014年07月24日 07:19:35 | mark.dickinson | link | issue22052 messages |
| 2014年07月24日 07:19:35 | mark.dickinson | create |
|