In unittest.mock.MagicMock I solve this problem by having __new__ create a new subclass for every instantiation. Setting any magic method on the instance is promoted to the type via __setattr__. That way every instance can have unique magic methods without affecting other instances.


On Sun, 23 Feb 2020 at 04:21, Jérôme Carretero <> wrote:
Thanks Josh for your prompt reply. All clear.



PS: Somehow I had never encountered a situation exacerbating the
subtleties of implicit invocations of special methods, and hadn't read
or integrated that section of the documentation, then when encountering
the “problem” I didn't make my way to the docs.
And now I also see that right when opening § 3.3. Special method
names ¶ 1 it's stated that “`x[i]` is roughly equivalent to
`type(x).__getitem__(x, i)`”. I'll be more careful next time!

On Sun, 23 Feb 2020 02:35:24 +0000
Josh Rosenberg <> wrote:

> This is explained in "Special Method Lookup":
> Short version: For both correctness and performance, special methods (those
> that begin and end with double underscores) are typically looked up on the
> class, not the instance. If you want to override on a per-instance level,
> have a non-special method that __str__ invokes, that can be overridden on a
> per-instance basis.
> On Sun, Feb 23, 2020 at 2:30 AM Jérôme Carretero <>
> wrote:
> > Hello,
> >
> >
> > I just noticed that calling `str(x)` is actually doing (in CPython
> > `PyObject_Str`) `type(x).__str__(x)` rather than `x.__str__()`.
> >
> > Context: I wanted to override __str__ for certain objects in order to
> > “see them better”.
> >
> > I'm wondering why not do `x.__str__()`
> >
> >
> > Best regards,
> >
> > --
> > Jérôme
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Michael Foord
Python Consultant, Contractor and Trainer