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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4