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.