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 email@example.com
> 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 firstname.lastname@example.org
> > 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