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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/GEOWJTBNMTE6KWCVR5AJTQNSWIRALXOD/
