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 <alex.moj...@gmail.com> wrote: > > > On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker <python...@gmail.com> > 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-le...@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/SLIFGO4FSMAM4AMZZX3B4Y3YQCNZACPE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Sebastian Kreft
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/4OYYVFNFOWY6ONW5YQAPF7R7QDS55YSL/ Code of Conduct: http://python.org/psf/codeofconduct/
