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 Tue, Apr 20, 2021 at 6:50 PM Chris Angelico <rosuav@gmail.com> wrote:
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
Hello, On Tue, 20 Apr 2021 18:23:15 -0000 "Pol Welter" <polwelter@gmail.com> wrote:
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 Wed, 21 Apr 2021 19:42:02 +0200 Pol Welter <polwelter@gmail.com> wrote:
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.
-- Best regards, Paul mailto:pmiscml@gmail.com
On Tue, Apr 20, 2021 at 6:50 PM Chris Angelico <rosuav@gmail.com> wrote:
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
Hello, On Tue, 20 Apr 2021 18:23:15 -0000 "Pol Welter" <polwelter@gmail.com> wrote:
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 Wed, 21 Apr 2021 19:42:02 +0200 Pol Welter <polwelter@gmail.com> wrote:
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.
-- Best regards, Paul mailto:pmiscml@gmail.com
participants (5)
-
André Roberge -
Chris Angelico -
Paul Sokolovsky -
Pol Welter -
Rob Cliffe