New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error message for incorrect call degraded in 3.7 #74719
Comments
I'm seeing doctest failures in Cython's test suite with Py3.7 due to the change of an error message: Failed example:
func1(arg=None)
Expected:
Traceback (most recent call last):
...
TypeError: func1() takes no keyword arguments
Got:
Traceback (most recent call last):
File "/opt/python/3.7-dev/lib/python3.7/doctest.py", line 1329, in __run
compileflags, 1), test.globs)
File "<doctest always_allow_keywords_T295.func1[2]>", line 1, in <module>
func1(arg=None)
TypeError: func1() takes exactly one argument (0 given) I'd normally just adapt the doctest and move on, but this seems like the error message is worse than before, so I thought I'd bring it up here. func1() is implemented as a METH_O C function. Suggesting that it does not accept keyword arguments seems better than saying that it expects "exactly one argument" instead of the exactly one argument that was passed. |
Example with a builtin function, abs(), which uses METH_O. Before: haypo@selma$ python3
Python 3.5.3 (default, Apr 24 2017, 13:32:13)
>>> abs(x=5)
TypeError: abs() takes no keyword arguments After: haypo@selma$ ./python
Python 3.7.0a0 (heads/master:85aba23, May 31 2017, 10:29:03)
>>> abs(x=5)
TypeError: abs() takes exactly one argument (0 given) In Python 3.5, PyCFunction_Call() starts by checking keyword arguments: if (flags == (METH_VARARGS | METH_KEYWORDS)) {
...
}
else {
if (kwds != NULL && PyDict_Size(kwds) != 0) {
PyErr_Format(PyExc_TypeError, "%.200s() takes no keyword arguments",
f->m_ml->ml_name);
return NULL;
}
switch (flags) {
case METH_NOARGS:
size = PyTuple_GET_SIZE(args);
if (size != 0) {
PyErr_Format(PyExc_TypeError,
"%.200s() takes no arguments (%zd given)",
f->m_ml->ml_name, size);
return NULL;
}
... In Python 3.7, _PyMethodDef_RawFastCallKeywords() first check positional arguments: switch (flags)
{
case METH_NOARGS:
if (nargs != 0) {
PyErr_Format(PyExc_TypeError,
"%.200s() takes no arguments (%zd given)",
method->ml_name, nargs);
goto exit;
}
if (nkwargs) {
goto no_keyword_error;
}
We can easily exchange the two checks, but IMHO we need an unit test (at least decorated by @cpython_only) to avoid regressions in the future. |
Ah, Python 3.6 is not affected: haypo@selma$ ./python
Python 3.6.1+ (heads/unpack_dict:ba4fb35, May 31 2017, 16:31:51)
>>> abs(x=5)
TypeError: abs() takes no keyword arguments |
I introduced the regression with the commit 7fc252a: "Optimize _PyCFunction_FastCallKeywords(): Issue bpo-29259: Write fast path in _PyCFunction_FastCallKeywords() for METH_FASTCALL, (...) Cleanup also _PyCFunction_FastCallDict(): (...) Move code to raise the "no keyword argument" exception into a new no_keyword_error label." |
See also "[Python-ideas] Positional-only parameters" discussion of last March: Brett Cannon: "It seems all the core devs who have commented on this are in the positive (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't explicitly vote). So to me that suggests there's enough support to warrant writing a PEP. (...)" (No, I didn't write such PEP yet :-p) Maybe we can also enhance the error message to explain that the function accepts exactly one positional-only argument? |
Note that some error messages are "takes no keyword arguments", but others are "does not take keyword arguments" or "doesn't take keyword arguments". They should be unified. What wording is better? |
We already have a _PyArg_NoKeywords() function. Maybe we could add a new _PyErr_NoKeywords() function which would just raise the error? |
The details can be different. For example: >>> 1 .__add__(x=2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: wrapper __add__ doesn't take keyword arguments The message contains the word "wrapper" and doesn't contains parenthesis. I think it can be extended for containing the type name ("int.__add__()" or "wrapper __add__ of in objects"), and this hard to do with general _PyErr_NoKeywords(). Let first unify messages, then try to add more useful information in messages and create a general API if this is possible. |
I vote for "takes no keyword arguments". |
Updated error messages. Later I'm going to unify error messages for Python and C functions. But this is a different issue. I can wrote a test, but I don't know good place for it. test_builtin doesn't look a good place to me. |
The tests could either go into the respective type's tests or a new test module like test_exception_messages could be added that's only to help keep messages in sync with each other. |
There is no respective type. abs() is just an arbitrary example. There are perhaps tens functions affected by this bug. test_exception_messages looks an overkill. There are similar tests in test_capi and test_getargs2 that test public PyArg_* functions. But this bug is related to other code. Hmm, may be test_call is an appropriate test. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: