Mailman 3 On function signature mismatch, include candidate function in traceback - Python-ideas - python.org

newer
Accepting a function argument of a...

On function signature mismatch, include candidate function in traceback

older
: str() vs format(): trivia...

Pol Welter

20 Apr 2021 20 Apr '21

11:53 p.m.

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

Reply

Sign in to reply online Use email software

Show replies by date

Rob Cliffe

21 Apr 21 Apr

3:15 a.m.

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/

Reply

Sign in to reply online Use email software

Chris Angelico

3:17 a.m.

On Wed, Apr 21, 2021 at 7:46 AM Rob Cliffe via Python-ideas 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

Reply

Sign in to reply online Use email software

André Roberge

3:32 a.m.

On Tue, Apr 20, 2021 at 6:50 PM Chris Angelico wrote:

On Wed, Apr 21, 2021 at 7:46 AM Rob Cliffe via Python-ideas 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/

Reply

Sign in to reply online Use email software

Paul Sokolovsky

4:50 a.m.

Hello, On Tue, 20 Apr 2021 18:23:15 -0000 "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'.

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

Reply

Sign in to reply online Use email software

Pol Welter

11:12 p.m.

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" 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

Reply

Sign in to reply online Use email software

Paul Sokolovsky

22 Apr 22 Apr

10:01 p.m.

Hello, On Wed, 21 Apr 2021 19:42:02 +0200 Pol Welter 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" 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

Reply

Sign in to reply online Use email software

1093

Age (days ago)

1095

Last active (days ago)

Download

6 comments

5 participants

tags

participants (5)

André Roberge
Chris Angelico
Paul Sokolovsky
Pol Welter
Rob Cliffe