Confusing traceback: Incorrect error line shown when `@property` is mistakenly applied to `__str__` method

[Ark-kun]

Bug report

Bug description:

The error message is TypeError: 'str' object is not callable, but the highlighted error line has no calls.

class MyClass:
    @property
    def __str__(self):
        return "MyClass"

obj = MyClass()

print(f"Hello, {obj}")

Traceback (most recent call last):
  File "<string>", line 9, in <module>
    print(f"Hello, {obj}")
                   ^^^^^
TypeError: 'str' object is not callable

CPython versions tested on:

3.14

Operating systems tested on:

Windows

[efimov-mikhail]

Thx for the report. You understand that property decorator is incorrect here and should be removed, don't you?

[terryjreedy]

'mistakenly applied' implies 'yes'. The confusing part of the error message is that 'str' should be __str__.
The bug is the apparent deletion of the underscores somewhere. (Note: this happens in various places, which is why the underscores in issue titles need to be protected by backticks.)

>>> obj.__str__ 
'MyClass'  # The property works.
>>> obj.__str__()
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    obj.__str__()
TypeError: 'str' object is not callable  # The property, misnamed, is not callable.
>>> try: print(obj)
... except TypeError as e: repr(e)
... 
'TypeError("\'str\' object is not callable")'  The misnaming appears to be in the message.
>>> repr("'__str__' is")
'"\'__str__\' is"'  # Repr does not delete underscores.

[terryjreedy]

This might or not be a viable feature request for an improved message, but it would be good to check prior issues. I did not relabel this as a bug for 3 reasons:

1. It is a generic problem with tracebacks is that they stop where python code invokes CPython C code, even if the C code invokes user Python code. Users trying to debug need to understand which special methods they code might be invoked this way.
2. We generally do not change exception messages in bugfix releases since this can break both production and test code.
3. Removing underscores may have been an early decision because sometimes disappearing would make messages variable, depending upon the hardware, software, and setup one uses. Dunder confusion is not unique to __str__.

A minimal reproducer follows:

>>> class C:
...     __str__ = 'C'
... 
>>> c = C()
>>> c.__str__()
Traceback (most recent call last):
  File "<pyshell#17>", line 1, in <module>
    c.__str__()
TypeError: 'str' object is not callable

The following is even more confusing.

>>> C.__add__ = 3
>>> c+3
Traceback (most recent call last):
  File "<pyshell#19>", line 1, in <module>
    c+3
TypeError: 'int' object is not callable
"

[efimov-mikhail]

The confusing part of the error message is that 'str' should be __str__.

Am I wrong that error message is only about type of dunder attributes? Those should be callable, because they are dunder methods. For example, if C.__add__ = 3 and C()+3 we actually try to call 3 with an argument, which is impossible.

[terryjreedy]

The user bug in all cases presented above is replacing methods with non-callable attributes. Clearly a mistake. The user complaint is that the resulting exception message is confusing. I consider it possible that this will be closed as "Won't fix". I gave some possible reasons, but it is not my decision.

[serhiy-storchaka]

This is expected behavior. obj.__str__ should be callable. str is not callable.

We could add an explicit check that tests if the special method can be called and raises a more descriptive error containing the class name and the name of the special method, but that would add a small overhead to each call to that special method and increase the maintenance burden. User error of this kind is rare, so I'm not sure the price we'd all pay for a better error message is worth it.

[serhiy-storchaka]

And the traceback is correct. __str__ does not raise an exception. The __str__ property succesfully returns a string. The problem occurs when we try to call that string, and the traceback correctly points at this.