On Fri, Aug 09, 2019 at 01:16:16AM +0100, Rob Cliffe via Python-Dev wrote:
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.
Correct. Why should we be embarrassed to be experienced programmers? For the record, I'm not a professional programmer, so my experience is probably a thousandth or less of that of some of the people here.
IMHO it's about as helpful to a newbie as saying GrobKunkError means that there's an error with the kunk of the grob.
To a programmer who is not a native English speaker, "ValueError" and "SyntaxError" makes as much sense as PHP's PAAMAYIM NEKUDOTAYIM operator makes to non-Hebrew speakers. If they can cope with learning what "Value" means, I'm sure we English-speakers can learn what "Target" and "Scope" mean. Developers are newbies for a tiny fraction of their programming life. Why should we ban technical terms because somebody in the first month of their programming life doesn't know the terms? They're going to learn them, and pretty quickly, as soon as they start talking to more experienced programmers, or reading answers on Stackoverflow, etc. "Scope" and "target" are standard terms of art, like class, function, variable, etc. Saying that we shouldn't use them makes as little sense as saying that chefs shouldn't use the terms "sauté", "braise" or "blanche" because newbie cooks don't know what they are. Of course they don't. Not knowing the things they need to know is the very definition of a newbie. Here are some exceptions which "make as much sense to a newbie as..." - BrokenPipeError (is my plumbing leaking? what do pipes have to do with programming?) - ChildProcessError (Child? Process?) - FutureWarning (something to do with Marty McFly or the Terminator?) - the confusingly named UnicodeDecodeError and UnicodeEncodeError which differ by two letters but mean completely different things, the complete opposite of each other. to mention only a few.
I think AmbiguousScopeError is somewhat better than TargetScopeError,
I would be fine with AmbiguousScopeError too, except for the unfortunately double s. But now we're bike-shedding. Either name is much more informative than "syntax error". [...]
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. [...]
I'm mildly curious as to why you couldn't rely on the error message, but I'm sure you had a good reason.
Error messages are not part of the API and could change at any time, including in bug fix releases. Over the last few years, we've made a lot of progress in making error messages more informative: python2.4 -c "len(None)" TypeError: len() of unsized object python2.7 -c "len(None)" TypeError: object of type 'NoneType' has no len() and they could easily continue to change in the future: python4000 -c "len(None)" TypeError: 'None' has no length -- Steven