This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: function with modified __name__ uses original name when there's an arg error
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.11
Status: open Resolution:
Dependencies: 2786 Superseder:
Assigned To: Nosy List: benjamin.peterson, berker.peksag, erickt, iritkatriel, jcea, martin.panter, mchelem, r.david.murray
Priority: normal Keywords: patch

Created on 2008-11-14 06:44 by erickt, last changed 2022-04-11 14:56 by admin.

File name Uploaded Description Edit
issue4322.patch mchelem, 2014-03-09 21:34 review
Messages (7)
msg75853 - (view) Author: Erick Tryzelaar (erickt) Date: 2008-11-14 06:44
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.
msg75886 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-11-14 21:39
This is because these errors use the code object's name attribute
(f.func_code.co_name) for error messages.
msg194424 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-08-04 21:05
I think fixing this is a valid request.
msg212988 - (view) Author: Michele dos Santos da Silva (mchelem) Date: 2014-03-09 21:34
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.
msg213183 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-11 22:56
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.
msg249573 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-09-02 21:10
Issue 2786 currently proposes to pass __qualname__; if accepted that might also satisfy this report.
msg407068 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-11-26 16:39
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
Date User Action Args
2022-04-11 14:56:41adminsetgithub: 48572
2021-11-26 16:39:47iritkatrielsetnosy: + iritkatriel

messages: + msg407068
versions: + Python 3.11, - Python 3.4
2015-09-02 21:10:13martin.pantersetnosy: + martin.panter
dependencies: + Names in function call exception should have class names, if they're methods
messages: + msg249573
2015-06-20 13:37:44berker.peksagsetnosy: + berker.peksag
2014-03-11 22:56:25r.david.murraysetnosy: + r.david.murray
messages: + msg213183
2014-03-09 21:34:25mchelemsetfiles: + issue4322.patch

nosy: + mchelem
messages: + msg212988

keywords: + patch
2013-08-04 21:52:41jceasetversions: + Python 3.4, - Python 3.0
2013-08-04 21:52:22jceasetnosy: + jcea

stage: resolved -> needs patch
2013-08-04 21:05:51benjamin.petersonsetstatus: closed -> open
resolution: not a bug ->
messages: + msg194424
2013-08-04 21:05:14benjamin.petersonlinkissue18656 superseder
2010-12-22 03:16:06r.david.murraysetstatus: open -> closed
nosy: benjamin.peterson, erickt
resolution: not a bug
stage: resolved
2008-11-14 21:39:46benjamin.petersonsetpriority: normal
nosy: + benjamin.peterson
messages: + msg75886
2008-11-14 06:44:18ericktcreate