Nick Coghlan wrote:
Terry Reedy wrote:
So I wonder whether the proper change might have been to remove
object.__init__.
That would have broken too much code, since a lot of immutable types
rely on it (they only override __new__ and leave __init__ alone).
In what way do they depend on the equivalent of "def f(): pass"?
If, during the object creation process, "if hasattr(newob, '__init__'):"
were added after calling cls.__new__ and before calling newob.__init__,
what dependency would be left?
To repeat a previous comment, the doc sentence beginning "If a base
class has an __init__() method," implies that it is intended to be
possible for classes to not have an __init__ method. Should the doc be
changed. Is this just a holdover from pre-object-class days?
For more info, see Guido's checkin changing the behaviour and the
associated tracker issue:
http://svn.python.org/view?rev=54539&view=rev
http://bugs.python.org/issue1683368
Ah yes. In that thread I complained that
>>> object.__init__.__doc__
'x.__init__(...) initializes x; see x.__class__.__doc__ for signature'
unchanged in 3.0) is uninformative. Why cannot object.__init__.__doc__
tell the truth?
"object.__init__(self) takes no other args and does nothing"
The signature of a class as a callable is *not* the signature of its
__init__ method!
In particular
>>> object.__class__.__doc__
"type(object) -> the object's type\ntype(name, bases, dict) -> a new type"
(also unchanged in 3.0) is irrelevant and uninformative as to whether
object.__init__ accepts (as it used to) or rejects (as it now does) args
other than 'self'.
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
