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 wchargin
Recipients docs@python, wchargin
Date 2020-09-03.20:30:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1599165050.43.0.0605757296817.issue41706@roundup.psfhosted.org>
In-reply-to
Content
The operator override dunder methods, like `__add__`, are described in
the “Data model” docs here:
<https://docs.python.org/3.10/reference/datamodel.html#object.__add__>

Those docs say:

> For instance, to evaluate the expression `x + y`, where `x` is an
> instance of a class that has an `__add__()` method, `x.__add__(y)` is
> called.

But this is not correct: `x + y` always uses `type(x).__add__`, which
may be different from `x.__add__` if `__add__` has been set directly on
the instance.

Demonstration:

```
class C:
    def __add__(self, other):
        return "from class"


c = C()
print(c + c)  # prints "from class"

c.__add__ = lambda other: "from instance"
print(c.__add__(c))  # prints "from instance"
print(type(c).__add__(c, c))  # prints "from class"

print(c + c)  # prints "from class"!
```

The same issue appears in the reversed operator dunder (`__radd__`,
et al.) docs below.

I have a patch that I can submit as a PR; just need a bpo number.
History
Date User Action Args
2020-09-03 20:30:50wcharginsetrecipients: + wchargin, docs@python
2020-09-03 20:30:50wcharginsetmessageid: <1599165050.43.0.0605757296817.issue41706@roundup.psfhosted.org>
2020-09-03 20:30:50wcharginlinkissue41706 messages
2020-09-03 20:30:50wchargincreate