The inspection `inspect.getfullargspec(object.__init__)` shows that `object.__init__` takes both varargs (starred) and varkw (double-starred) arguments.* However, it is impossible to call `object.__init__` with varargs or varkw arguments.

If one tries to call `object.__init__(SomeClass(), ...)` with either of those arguments, the following error is raised:

`TypeError: SomeClass.__init__() takes exactly one argument (the instance to initialize)`.

This error is not raised if `SomeClass()` is replaced with some literal, e.g. a number.



* I can not certify whether it is intended behavior or a bug, because the signature of `obj.__init__` takes those arguments.

Well, as you note, technically object.__init__ does take args and kwargs. It just raises an exception if if finds any. What are you proposing to change here?

My suggestion:

Although both `object(...)` and `object.__init__(...)`, run through the same method, they are semantically and intentionally different.

1. `ObjectType(...)`; implicit call of `object.__init__`: The user intends to create an object. If extra arguments given, the following error should rise:

	'TypeError: Obj() takes no arguments'

This error is already raised from `object.__new__` before `object.__init__` is invoked -- the init function is not reached at all.

2. `object.__init__(object_instance, ...)`; explicit call of `object.__init__`: The user intends to call the `__init__` function for some reason beyond object instance creation. If n-ary arguments given, the following error should *not* rise:

	'ObjectType.__init__() takes exactly one argument (the instance to initialize)'


One reason I suggest the error should be eliminated is the message is confusing; while `object.__init__` has been called, the name of the non-existing `ObjectType.__init__` method appears on the error message.

3. `object_instance.__init__(...)` where `type(object_instance) == object`: Same behavior as (2).

4. `object_instance.__init__(...)` where `type(object_instance)` is a subclass of `object`: Same behavior as (3).


This is one possible solution I can think of -- which also makes the title sort of misleading. This is of course in the case that there are no use-cases making the `object.__init__` exception necessary. However, even in those cases, the implicit and explicit init calls might be distinguishable and the exception may be raised outside `object.__init__`, e.g. by the parser before calling the init.