On Thu, Aug 08, 2019 at 10:00:01AM -0700, Barry Warsaw wrote:
"The two invalid cases listed above raise TargetScopeError, a new subclass of SyntaxError (with the same signature).”
The PEP doesn’t really go into the rationale for why a new exception is being defined, and in the issue I’ve argued that we should just raise SyntaxError in those cases. To me, “TargetScopeError” is pretty obscure and doesn’t give users an obvious clue as to what’s going wrong, without searching the interwebs.
It's not a syntax error. There's nothing wrong with the syntax per-say: we still have ``target := expression``. There's a problem with the *semantics* not the syntax. The name is perfectly self-descriptive: TargetScopeError means that there's an error with the scope of the target. What else could it mean? What's wrong with having to look up an unfamiliar exception by searching the interwebs? The first few times I hit KeyError, I had no idea what a "key" was (I was a beginner) and if I had internet access, I would have looked it up on the web. I didn't, so I looked it up in the book I was reading. The first times I hit UnboundLocalError, I did have internet access, so I googled it. Once I understood that it meant that the local I was trying to use was unbound, and that "unbound" mean "undefined", all was clear. (Well, not all, I still had to work out why it was undefined. But at least the exception name was more clear.) One of the frustrations I have is that it's near to impossible to programmatically distinguish wrong number of arguments from bad keyword arguments from providing the wrong type of argument without relying on the error message. (And yes, I have needed to do this.) All of these raise the same TypeError, even though only one of them is an actual error with the type: len(1) # An actual TypeError len([], None) # The type of the argument is fine. len(spam=[]) # The type of the argument is fine. Please let's not use SyntaxError for something that's not an error with the syntax. -- Steven