Mehrzad <[email protected]> added the comment:
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.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue44985>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
