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.