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/
