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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
