[Python-Dev] py3k: TypeError: object.__init__() takes no parameters

Nick Coghlan ncoghlan at gmail.com
Sat Jan 17 01:38:47 CET 2009


Terry Reedy wrote:
> Given
>  "The second use case is to support cooperative multiple inheritence in
> a dynamic execution environment. ... Good design dictates that this
> method have the same calling signature in every case (because the order
> of parent calls is determined at runtime and because that order adapts
> to changes in the class hierarchy)."
> the change makes object unsuitable as a multiple inheritance base.
> 
> I think as a practical matter it is anyway since practical cases have
> other methods that object does not have that need exist in the pyramid
> base.  This must be why there have not been squawks about the change in
> 2.6.

I think that sums up the reasoning fairly well - the (IMO, reasonable)
expectation is that a CMI hierarchy will look something like:

object
   |
CMIBase
   |
<CMI Heirarchy>

While the signatures of __new__ and __init__ will remain the same for
all classes in the CMI hierarchy, CMIBase will assume the only class
after it in the MRO is object, with signatures for __new__ and __init__
that accept no additional arguments beyond the class and instance
respectively.

Note that CMIBase serves another purpose in such a hierarchy:
isinstance(obj, CMIBase) becomes a concise check to see if an object is
a member of the hierarchy or not.

> 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).

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


More information about the Python-Dev mailing list