-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
Improve the error message logic for object_new & object_init #75687
Comments
As described in https://blog.lerner.co.il/favorite-terrible-python-error-message/, object_new and object_init currently have "object" hardcoded in the error messages they raise for excess parameters: >>> class C: pass
...
>>> C(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object() takes no parameters
>>> c = C()
>>> c.__init__(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object.__init__() takes no parameters This hardcoding makes sense for the case where that particular method has been overridden, and the interpreter is reporting an error in the subclass's call up to the base class, rather than in the call to create an instance of the subclass: >>> class D:
... def __init__(self, *args):
... return super().__init__(*args)
...
>>> D(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __init__
TypeError: object.__init__() takes no parameters However, it's misleading in the case where object_new is reporting an error because it knows object_init hasn't been overridden (or vice-versa), and hence won't correctly accept any additional arguments: in those cases, it would be far more useful to report "type->tp_name" in the error message, rather than hardcoding "object". If we split the error message logic that way, then the first two examples above would become: >>> class C: pass
...
>>> C(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C() takes no parameters
>>> c = C()
>>> c.__init__(10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C.__init__() takes no parameters while the subclassing cases would be left unchanged. |
Not sure this is easy issue. It requires taking to account many different cases and analyzing many arguments checking code scattered around many files. |
Fortunately, the logic is already well encapsulated: there's a "if (excess_args && (case A || case B)) {... report error ...}" check at the start of each of object_new and object_init, where "case A" = "the other function in the object_new/object_init pair has *not* been overriden" and "case B" is "this function *has* been overridden". That means the only change needed is to include the type name in an updated error message in case A, while retaining the current error messages for case B. |
It is not so easy to make an error message conforming with error messages for similar types. This may require changing error messages in other code. First, "takes no arguments" instead of "takes no parameters". For normal __new__ and __init__ you never got "takes no arguments". They take at least one argument -- a class or an instance. >>> tuple.__new__(tuple, 1, 2, 3, 4)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: tuple expected at most 1 arguments, got 4
>>> list.__init__([], 1, 2, 3, 4)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: list expected at most 1 arguments, got 4
>>> class C:
... def __new__(cls): return object.__new__(cls)
... def __init__(self): pass
...
>>> C.__new__(C, 1, 2, 3, 4)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __new__() takes 1 positional argument but 5 were given
>>> C.__init__(C(), 1, 2, 3, 4)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __init__() takes 1 positional argument but 5 were given |
For this issue, I'm not proposing to make any change other than to solve the specific problem reported in the blog post: when the method itself isn't overridden, then the error message should report the name of the most derived class, not "object", to help users more readily find the likely source of their problem (a missing "__init__" method definition). Making these custom errors consistent with Python 3's otherwise improved argument unpacking errors would be a separate issue (and I agree *that* change wouldn't qualify as being easy). |
What do you expect for: class C: pass
object.__new__(C, 1)
C.__new__(C, 1) |
Those would both report "C() takes no parameters" without further enhancements (which would be out of scope for this issue). The proposed improvement here isn't "Let's make the error message exactly correct in all cases" (that's probably impossible, since we've lost relevant information by the time the argument processing happens). Instead, it's "let's make the error message more helpful in the most common case for beginners, and let the folks performing the more advanced operation of calling __new__ directly do the translation if they need to" |
Reopening, as I was a little hasty with the merge button: the merged PR also changed the I'm also wondering if we should change the up-call case to *always* report the method name. That is, we'd implement the following revised behaviour: # Without any method overrides
class C:
pass
# With method overrides
class D:
def __new__(cls, *args, **kwds):
super().__new__(cls, *args, **kwds)
def __init__(self, *args, **kwds):
super().__init__(*args, **kwds)
|
I filed bpo-31527 as a follow-up issue to see whether or not it might be possible to amend the way these custom errors are generated to benefit from the work that has gone into improving the error responses from PyArg_ParseTupleAndKeywords. |
C.__new__(42) emits different error, "TypeError: object.__new__(X): X is not a type object (int)". Perhaps you meant C.__new__(C, 42) which now emits "TypeError: C() takes no arguments". Messages "object.__new__() takes no arguments" and "object.__init__() takes no arguments" are not correct since both object.__new__() and object.__init__() take one argument -- a class and an instance correspondingly. |
Aye, the "C.__new__" example omitting the first arg was just an error in that example. And that's a good point about the current "object.__init__()" error message actually being incorrect, since the *methods* each take exactly one argument - it's only the "object(*args, **kwds)" form that genuinely expects zero arguments. If we were to correct that error as well, we'd end up with the following: # Without any method overrides
class C:
pass
# With method overrides
class D:
def __new__(cls, *args, **kwds):
super().__new__(cls, *args, **kwds)
def __init__(self, *args, **kwds):
super().__init__(*args, **kwds)
|
I'll work on a fix for this and issue a PR. |
I think the main problem is not with coding, but with design. And from this point of view this may be not so easy issue. Let wait until Nick has a time to work on it. |
Nick, I think the error messages are incorrect. We expect error message to be I think for the class without any method overrides, the functionality should be something like this: >>> class C:
... pass
...
>>> C(42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C() takes no arguments
>>> C.__new__(C, 42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C() takes no arguments
>>> C().__init__(42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C().__init__() takes no arguments
>>> object.__new__(C, 42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C() takes no arguments
>>> object.__init__(C(), 42)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: C().__init__() takes no arguments Is that correct? |
Aye, I think Sanyam's proposed messages look good, and the "C().__init__() takes no arguments" wording is easier to follow than my suggested "C.__init__() takes exactly one argument" wording (as interpreting the latter currently requires noticing that it's referring to the *unbound* method taking one argument: the instance). |
Thanks for the feedback and updates folks! If we decide to make any further changes, I think they will be best handled as a new issue :) |
Serhiy, can you please elaborate on that a bit? I'll try to fix this. |
Error messages "object.__init__() takes no arguments" and "object.__new__() takes no arguments" are wrong. They contradicts the following error messages: >>> object.__init__()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: descriptor '__init__' of 'object' object needs an argument
>>> object.__new__()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: object.__new__(): not enough arguments |
I think this change should be reverted. |
We added the method names to help provide a nudge that the issue is likely to be a missing method implementation in the subclassing case, so I'd like to keep them if we can find a way to make the messages accurate again. What if we updated the offending format strings in typeobject.c to state the exact nature of the expected argument that is missing? PyErr_SetString(PyExc_TypeError, "object.__init__() takes exactly one argument (the instance to initialize)");
PyErr_Format(PyExc_TypeError, "%.200s.__init__() takes exactly one argument (the instance to initialize)", type->tp_name);
|
I am not sure if the following is resolved by your proposal, I post it just in case: |
Paolo: it still won't be completely clear, since there's still the subtle issue that __new__ is a static method rather than a class method, so the correct calls up to the base class are respectively:
|
The revised behaviour now makes the error messages consistent with each other: >>> class TooManyArgs():
... def __new__(cls):
... super().__new__(cls, 1)
...
>>> TooManyArgs()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __new__
TypeError: object.__new__() takes exactly one argument (the type to instantiate)
>>> class NotEnoughArgs():
... def __new__(cls):
... super().__new__()
...
>>> NotEnoughArgs()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __new__
TypeError: object.__new__(): not enough arguments
>>> class TooManyInitArgs():
... def __init__(self):
... super().__init__(1, 2, 3)
...
>>> TooManyInitArgs()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __init__
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
>>> class NotEnoughInitArgs():
... def __init__(self):
... object.__init__()
...
>>> NotEnoughInitArgs()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in __init__
TypeError: descriptor '__init__' of 'object' object needs an argument |
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: