This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 <>
> "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()
    >>> A() < B()

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.
Date User Action Args
2014-07-24 07:19:35mark.dickinsonsetrecipients: + mark.dickinson, r.david.murray, docs@python
2014-07-24 07:19:35mark.dickinsonsetmessageid: <>
2014-07-24 07:19:35mark.dickinsonlinkissue22052 messages
2014-07-24 07:19:35mark.dickinsoncreate