On function signature mismatch, include candidate function in traceback

Consider the following snippet: ``` def foo(a, b): pass foo(1, 2, 3) ``` We all know what will happen. ``` File "<stdin>", line 4, in <module> foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ``` Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'. There are situations (e.g. monkey patch) where this is not obvious. Would be great detail to include that in the traceback, I think. Best Pol

On 20/04/2021 19:23, Pol Welter wrote:
Consider the following snippet:
``` def foo(a, b): pass
foo(1, 2, 3) ```
We all know what will happen.
``` File "<stdin>", line 4, in <module> foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ```
Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'. And presumably the module name as well. If foo had been imported from a different module instead of defined in the current one, the line number alone would be less helpful. Rob Cliffe
There are situations (e.g. monkey patch) where this is not obvious. Would be great detail to include that in the traceback, I think.
Best Pol _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MINLM7... Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, Apr 21, 2021 at 7:46 AM Rob Cliffe via Python-ideas <python-ideas@python.org> wrote:
On 20/04/2021 19:23, Pol Welter wrote:
Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'. And presumably the module name as well. If foo had been imported from a different module instead of defined in the current one, the line number alone would be less helpful.
Maybe the easiest/best way would be to have a reference to the function itself available on the exception object? ChrisA

On Tue, Apr 20, 2021 at 6:50 PM Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Apr 21, 2021 at 7:46 AM Rob Cliffe via Python-ideas <python-ideas@python.org> wrote:
On 20/04/2021 19:23, Pol Welter wrote:
Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'. And presumably the module name as well. If foo had been imported from a different module instead of defined in the current one, the line number alone would be less helpful.
Maybe the easiest/best way would be to have a reference to the function itself available on the exception object?
I personally think that the easiest/best way would be for Python to use something like "<stdin-N>" as a "file" name in its repl and in exec, and use linecache to store each file. This way, the file content (and line number, etc.) could be retrieved and included in the traceback. This is often done in other REPLs (such as IPython and IDLE's pyshell). André Roberge ChrisA
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XU72HF... Code of Conduct: http://python.org/psf/codeofconduct/

Hello, On Tue, 20 Apr 2021 18:23:15 -0000 "Pol Welter" <polwelter@gmail.com> wrote:
Consider the following snippet:
``` def foo(a, b): pass
foo(1, 2, 3) ```
We all know what will happen.
``` File "<stdin>", line 4, in <module> foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ```
Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'.
There are situations (e.g. monkey patch) where this is not obvious. Would be great detail to include that in the traceback, I think.
That was reported some time ago: https://groups.google.com/g/dev-python/c/xdcpSJN17QQ https://groups.google.com/g/python-ideas/c/3jEZ9F-oUr0 Just as you, I had hard time to believe that wasn't fixed over 30 years of CPython history. I fixed that in my Python dialect, https://github.com/pfalcon/pycopy , and enjoyed it thoroughly on multiple occasions since then. For the snippet above (put in a file): Traceback (most recent call last): File "ex.py", line 4, in <module> File "ex.py", line 2, in foo TypeError: foo() takes 2 positional arguments but 3 were given -- Best regards, Paul mailto:pmiscml@gmail.com

Hah, should have put more effort in my research then. And so recent too. Well, it is not something easy to search for. I read the other thread, and I am inclined to agree with Paul. Whether or not the execution enters the function (as in: new entry in the call stack) during setup is really an implementation detail. For the very same reason, I also see why the CPython devs don't want to include a fake extra stack layer. Still, personally, I think that during the checking of the function arguments, execution is logically closer to the function than the point where it was called. I also think that the stack part of the traceback *is* the right place to display this information. I'd also be fine with an extended exception message though. In the end, I think this is a trivial improvement. (Trivial as in 'no adverse side effects', not trivial to implement). Regardless if it has affected many users in the past or not (I'd say it did!). I am anything but an authoritative figure on the matter, so just consider this a firm +1 from another user. Cheers Pol On 2021-04-21 01:20, Paul Sokolovsky wrote:
Hello,
On Tue, 20 Apr 2021 18:23:15 -0000 "Pol Welter" <polwelter@gmail.com> wrote:
Consider the following snippet:
``` def foo(a, b): pass
foo(1, 2, 3) ```
We all know what will happen.
``` File "<stdin>", line 4, in <module> foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ```
Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'.
There are situations (e.g. monkey patch) where this is not obvious. Would be great detail to include that in the traceback, I think. That was reported some time ago:
https://groups.google.com/g/dev-python/c/xdcpSJN17QQ https://groups.google.com/g/python-ideas/c/3jEZ9F-oUr0
Just as you, I had hard time to believe that wasn't fixed over 30 years of CPython history.
I fixed that in my Python dialect, https://github.com/pfalcon/pycopy , and enjoyed it thoroughly on multiple occasions since then. For the snippet above (put in a file):
Traceback (most recent call last): File "ex.py", line 4, in <module> File "ex.py", line 2, in foo TypeError: foo() takes 2 positional arguments but 3 were given

Hello, On Wed, 21 Apr 2021 19:42:02 +0200 Pol Welter <polwelter@gmail.com> wrote:
Hah, should have put more effort in my research then. And so recent too. Well, it is not something easy to search for.
I read the other thread, and I am inclined to agree with Paul. Whether or not the execution enters the function (as in: new entry in the call stack) during setup is really an implementation detail. For the very same reason, I also see why the CPython devs don't want to include a fake extra stack layer.
Still, personally, I think that during the checking of the function arguments, execution is logically closer to the function than the point where it was called. I also think that the stack part of the traceback *is* the right place to display this information.
I'd also be fine with an extended exception message though.
In the end, I think this is a trivial improvement. (Trivial as in 'no adverse side effects', not trivial to implement). Regardless if it has affected many users in the past or not (I'd say it did!).
I am anything but an authoritative figure on the matter, so just consider this a firm +1 from another user.
Thanks. I believe there was a suggestion in the previous threads to post a https://bugs.python.org/ ticket on that. Where it stopped for me so far is: I wanted to have a look at CPython source code to have more informative argument [to add another backtrace entry] than just "I did it on another Python implementation, it was easy". But then I travelled and switched to other set of projects, which keep me busy for the foreseeable future. So, if you're interested, feel free to post a ticket to (hopefully) get this matter going further.
Cheers Pol
On 2021-04-21 01:20, Paul Sokolovsky wrote:
Hello,
On Tue, 20 Apr 2021 18:23:15 -0000 "Pol Welter" <polwelter@gmail.com> wrote:
Consider the following snippet:
``` def foo(a, b): pass
foo(1, 2, 3) ```
We all know what will happen.
``` File "<stdin>", line 4, in <module> foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ```
Would it be reasonable to include the line number for the function `foo()` that it resolved the call to? I.e. 'File "<stdin>", line 1, in foo'.
There are situations (e.g. monkey patch) where this is not obvious. Would be great detail to include that in the traceback, I think. That was reported some time ago:
https://groups.google.com/g/dev-python/c/xdcpSJN17QQ https://groups.google.com/g/python-ideas/c/3jEZ9F-oUr0
Just as you, I had hard time to believe that wasn't fixed over 30 years of CPython history.
I fixed that in my Python dialect, https://github.com/pfalcon/pycopy , and enjoyed it thoroughly on multiple occasions since then. For the snippet above (put in a file):
Traceback (most recent call last): File "ex.py", line 4, in <module> File "ex.py", line 2, in foo TypeError: foo() takes 2 positional arguments but 3 were given
-- Best regards, Paul mailto:pmiscml@gmail.com
participants (5)
-
André Roberge
-
Chris Angelico
-
Paul Sokolovsky
-
Pol Welter
-
Rob Cliffe