On Wed, Mar 04, 2020 at 01:08:35AM -0800, Andrew Barnert wrote:
> I liked everything up to using magic numbers like this.
I'm not wedded to the idea of error number. I chose them because I
expect there will only be a few of them (three?) and the majority
of the time you won't bother to check the number.
If you are debugging an exception that occurs in code that's supposed to
be working, you have a bug and you will read the error message to find
out what it means, not inspect the error number. It's only when you
intentionally capture the exception that the error number might matter,
and even then probably not that often.
I expect that in the majority of cases, there's only one possible
failure mode. E.g. you can't have both too many and too few arguments in
the same call, and you'll know which is going to be the case:
try:
spam(1, 2)
except ParameterError:
# Some versions of spam only accept 1 argument;
# some accept 2. If we get a ParameterError, we
# must be running the old 1-arg version.
Another alternative is to testing for key phrases in the exception
message:
if "too few arguments" in err.args[0]: ...
but that's fragile and only works until the message gets changed to say
"not enough arguments". (The error message is not part of the API, so it
can change without warning.)
But as I said, I don't think this part of the proposal would be used
very often, and if it becomes a real sticking point I'd be prepared to
drop it. The important thing is to be able to programmatically
distinguish the case where arguments don't match the parameters from the
case where an argument is the wrong type.
> Nobody will remember whether it’s 1 for too many arguments or too
> few;
If we use an error number, I will beg for the numbers to be documented
in the exception docstring so that `help(ParameterError)` will show the
list. I don't expect that there will be many. I can only think of three,
even if there is triple that it's still small enough to put into the
docstring.
But this is just arguing about the colour of the bikeshed. Do you agree
with me that the bikeshed itself is useful?
> The other question: what exactly do you propose to change? I don’t
> think you can do this on the caller side (the ceval bytecode handler
> and the PyCall functions).
I don't know enough about the Python internals to give a definitive
answer, but I'm assuming/hoping that there is a single, or at most a
few, places in the interpreter that matches up arguments to formal
parameters, and if there's a discrepency it currently raises TypeError.
PyCall sounds promising :-)
> That still leaves functions that
> parse *args and **kw and raise TypeError manually, whether in Python
> or in C, but I suppose you can say that in that case it really isn’t a
> parameter error (the signature really is *args, **kw so everything
> matches).
Indeed.
I don't have any expectations about those functions. If the maintainer
of the function eventually changes whatever error they are currently
raising to ParameterError, that will be grand, but I don't expect every
third-party function that implements some custom variety of parameter
handling to support this. If they do, great, if they don't, we're no
worse off than the status quo.
> What about inspect.Signature.bind?
Do you have a specific concern?
Signature.bind promises to raise TypeError if the arguments don't match
the parameters. A change to ParameterError should be completely
backwards compatible since it will be a subclass of TypeError.
--
Steven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/D44ZJK5YFPBGFOEQNFUB2MDWWTFCPXFM/
Code of Conduct: http://python.org/psf/codeofconduct/
