I also would prefer richer exceptions especially if it can be done without introducing any other problems.
In the same vein, I once suggested a richer inheritance failure message (this, basically: https://github.com/NeilGirdhar/inheritance_graph), for which if I remember correctly Guido was mildly supportive. I didn't have time to make a proposal patch. On Monday, March 2, 2020 at 4:32:35 PM UTC-5, Sebastian Kreft wrote: > > 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....@gmail.com <javascript:>> > wrote: > >> >> >> On Mon, Mar 2, 2020 at 12:47 AM Christopher Barker <pyth...@gmail.com >> <javascript:>> 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...@python.org <javascript:> >> To unsubscribe send an email to python-id...@python.org <javascript:> >> 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/3VAQCFWB2ZWJXJGFLSZOXTFTEWRI2YK2/ Code of Conduct: http://python.org/psf/codeofconduct/
