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.