[Python-ideas] Generator unpacking

[Andrew Barnert]

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.
> 
> 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.)

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. When that's insufficient or misleading (as with the ever-popular missed-')' errors), printing the token or AST node itself would probably just make it more misleading. And, as for putting it in the error object, it's pretty rare that anyone handles SyntaxError in code (unlike KeyError, FileNotFoundError, etc.), so that seems a lot less useful.

Maybe there is a clean way to improve SyntaxError akin to KeyError, but it would take a lot more thought and design (and probably argument), so I'd work on KeyError first.