On 08/08/2019 22:58:15, Steven D'Aprano wrote:
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? That's easy for an experienced programmer to say. IMHO it's about as helpful to a newbie as saying GrobKunkError means that there's an error with the kunk of the grob.
I think AmbiguousScopeError is somewhat better than TargetScopeError, but perhaps someone will think of something even better. (ScopeConflictError? InvalidVariableReuse? I dunno.)
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.) Sure, people should be encouraged to look things up on the web (if they haven't already acquired the habit). But that doesn't mean we shouldn't make things as clear as reasonably possible in the first place.
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. (For reference the error messages are, depending a bit on the Python version, respectively object of type 'int' has no len() len() takes exactly one argument (2 given) len() takes no keyword arguments . .) I'm mildly curious as to why you couldn't rely on the error message, but I'm sure you had a good reason. FWIW IMHO the last two ought to produce an exception called ArgumentError or ParameterError or some such or even more specific names such as TooManyArguments and KeywordArgumentsDisallowed. I guess I'm agreeing with you to the extent that I'm proposing more (specific) exceptions. Rob Cliffe