There was a proposal (by me) some time ago to add some structured
information to some of the Exceptions. See
https://www.python.org/dev/peps/pep-0473/, but it finally got rejected due
to being too broad. I'd be happy to revive (parts of) the proposal if
anyone is interested.
I managed though to create a PR adding a name attribute to NameError, see
https://github.com/python/cpython/pull/6271 and
https://bugs.python.org/issue37797.
On Mon, Mar 2, 2020 at 6:01 PM Alex Hall
On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker
wrote: That being said, more information is better than less, so maybe an unpacking error should show the *value* of what was being unpacked:
a, b = 1, 2, 3 Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: too many values to unpack (expected 2)
Which, in fact, is what iPython already does:
In [5]: a,b = 1,2,3
--------------------------------------------------------------------------- ValueError Traceback (most recent call last) <ipython-input-5-402193b14bdc> in <module> ----> 1 a,b = 1,2,3
ValueError: too many values to unpack (expected 2)
The only extra thing IPython is doing here is showing the source line, which it can do because it saves the input in linecache. The standard shell never saves its input so it never shows in tracebacks. I do think that's an issue, but if you ran these examples in files you'd get the same amount of information either way.
(cause it's showing the line of code, not the run time values)
There are many tools which enhance tracebacks with local variables. Even the standard traceback module can do it. But of course improving the default experience with just the right amount of information would be ideal.
So if possible, it would be great if error messages did generally show the value(s) of the objects involved, if possible.
Then that would be:
ValueError: too many values to unpack (expected 2, got : 'this')
Given that it's a ValueError, it seem the *value* should be known, and generally relevant.
And this is already done for some ValueErrors:
In [3]: i = int('45f')
--------------------------------------------------------------------------- ValueError Traceback (most recent call last) <ipython-input-3-45f7234bd5b5> in <module> ----> 1 i = int('45f')
ValueError: invalid literal for int() with base 10: '45f'
Maybe it should be for ALL Value Errors?
In general Python error messages don't include the relevant values or much information about them, although I often wish they would. For example when I get a KeyError I wish I could see which keys are present, unless there's too many for it to be practical. I'm speculating, but I think there are two main reasons for this:
1. To avoid executing arbitrary __repr__ methods. 2. To avoid the performance cost of creating a message for an exception that may be caught and thrown away.
Neither of these really apply to int('45f').
Are there any other major reasons for the general lack of information? It feels like an intentional decision beyond implementation difficulty. I imagine we can work around both reasons:
1. There's a lot of information that can be extracted and displayed without running any user defined code. 2. Objects can be saved (such as the dict that raised KeyError) while deferring the message rendering until it's requested. _______________________________________________ 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/SLIFGO... Code of Conduct: http://python.org/psf/codeofconduct/
-- Sebastian Kreft