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.

Issue 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