[Python-ideas] Generator unpacking

[Steven D'Aprano]

On Mon, Feb 15, 2016 at 01:55:32PM -0800, Andrew Barnert via Python-ideas wrote:
> On Feb 15, 2016, at 07:13, Sven R. Kunze <srkunze at mail.de> wrote:
> > 
> >> On 15.02.2016 15:42, Steven D'Aprano wrote:
> >> I believe you are misinterpreting the error. The error isn't that you
> >> are trying to assign to the literal [1,2]. The error is that you are
> >> trying to assign to the literal 1. It's a subtle difference,
> > 
> > You are indeed right.
> > 
> > And while we are on it, that reminds me of KeyError. I always feel 
> > annoyed by the fact that Python doesn't tell me what key a dict is 
> > missing.

Showing the missing key in the error message goes all the way back to 
Python 1.5:

[steve at ando ~]$ python1.5 -c '{}["spam"]'
Traceback (innermost last):
  File "<string>", line 1, in ?
KeyError: spam

Admittedly, the exception object itself doesn't keep a reference to the 
missing key, so you can't programmatically query it for the key, but 
normally that's not a problem since you just tried to look it up so you 
should still have the key.


> > So, if I were to make a suggestion, I would like to see the 
> > issue-causing thing to be mentioned in those two types of 
> > exceptions.
> 

> IIRC, there's a series of bugs on adding more useful information to 
> the builtin exceptions, which includes putting the key in the error 
> message _and_ as an attribute of the exception (a la filename in the 
> filesystem exceptions), but they've been waiting on someone to do the 
> work for a few years now. If so, there's an obvious way to kick-start 
> the solution: find the bug and write a patch. (I suspect some people 
> would object to fixing KeyError without also fixing IndexError, and 
> want to argue about whether the key member goes in each exception 
> directly or is part of LookupError, and so on, and there's the more 
> substantive issue of keeping alive potentially-large keys, and so on, 
> so it probably won't be as simple as "submit a trivial patch and it 
> gets accepted", but at least having a patch would get the process 
> moving.)


See discussion here: http://bugs.python.org/issue18162

Also http://bugs.python.org/issue1182143

And the PEP: https://www.python.org/dev/peps/pep-0473/


> But for SyntaxError, there is no object to stick in the error object 
> or error message, just a source token or an AST node. Both of those 
> have pointers back to start and end in the source string, and that's 
> what goes into the SyntaxError, which is already shown to the user by 
> printing the relevant line of source and pointing a caret at it.

Sadly, CPython doesn't manage to even display the caret at all:

[steve at ando ~]$ python -c "[a, 2] = 'xy'"
  File "<string>", line 1
SyntaxError: can't assign to literal



Jython gives a much more informative error:

steve at orac:~$ jython -c "[a, 2] = 'ab'"
  File "<string>", line 1
    [a, 2] = 'ab'
       ^
SyntaxError: can't assign to number


-- 
Steve