I ran into a case where I modified the __name__ attribute of a function
and then didn't specify the right number of arguments, and I got a
TypeError that used the original function name, as demonstrated here:

>>> def foo(): pass
... 
>>> foo.__name__ = 'bar'
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes no arguments (1 given)

I would have expected it to say "TypeError: bar() ...". I'm guessing
that the interpreter isn't using the __name__ attribute in this case.

This is because these errors use the code object's name attribute
(f.func_code.co_name) for error messages.

I think fixing this is a valid request.

func_name was not available on the places where the error strings are set (PyErr_Format), so I added it and passed it around as needed.

This is the simplest approach, but I am not sure it is the best (newbie here). Thus, I am waiting for your comments to improve the solution.

pjenvey noted I cannot just change PyEval_EvalCodeEx, since it is part of the interface. I intend to write a new function and call it from the old interface, setting func_name to co_name.

Before I do that, I want to check if this design is correct. Also, I am not sure what this new function would be called, I am not even sure what the "Ex" means in PyEval_EvalCodeEx.

The 'Ex' generally means "this is a public API but we needed to change it, so we made a new function with an extended API". Which means yours would be PyEval_EvalCodeExEx, I suppose :)

Seriously, though, I don't know what we actually do in a case like this. I don't touch the C code very often myself. Hopefully Benjamin will find time to take a look.

bpo-2786 currently proposes to pass __qualname__; if accepted that might also satisfy this report.

Reproduced on 3.11:

>>> def foo(): pass
... 
>>> foo.__name__ = 'bar'
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes 0 positional arguments but 1 was given

When too many arguments are passed to a function, a TypeError is generated using __qualname__. I created a PR that solves the problem by updating the __qualname__ attribute when the function's __name__ attribute is changed. I know it's not a very good solution so I'm waiting for your ideas and suggestions.

I'm not sure I agree that there is a problem. ISTM that reporting the original __qualname__ is useful because it can be related back the original source code. Presumably, that is what you really want when tracking down a bug.

I also don't see a problem here. If you change __qualname__, the error message reflects that:

>>> def foo(): pass
... 
>>> foo.__qualname__ = "bar"
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: bar() takes 0 positional arguments but 1 was given