This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients KayEss, Rhamphoryncus, benjamin.peterson, blakeross, eric.snow, georg.brandl, gregory.p.smith, gvanrossum, jaraco, jcea, jonash, rhettinger, terry.reedy
Date 2014-05-28.22:57:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1401317872.06.0.391759759804.issue1683368@psf.upfronthosting.co.za>
In-reply-to
Content
Hrm. I've always thought that the key point of cooperative MI was the term *cooperative*. Consider a regular (non-constructor) method. You must have a common base class that defines this method, and *that* method shouldn't be calling the super-method (because there isn't one). All cooperative classes extending this method must derive from that base class.

It's the same for __init__ and __new__, except that you may treat each (keyword) argument as a separate method. But you must still have a point in the tree to "eat" that argument, and that point must not pass it up the super call chain.

If in a particular framework you want unrecognized keyword arguments to the constructor to be ignored, you should define a common base class from which all your cooperative subclasses inherit. But given the prevalence of *single* inheritance, 'object' shouldn't be that common base class.
History
Date User Action Args
2014-05-28 22:57:52gvanrossumsetrecipients: + gvanrossum, georg.brandl, rhettinger, terry.reedy, gregory.p.smith, jcea, jaraco, Rhamphoryncus, blakeross, benjamin.peterson, KayEss, jonash, eric.snow
2014-05-28 22:57:52gvanrossumsetmessageid: <1401317872.06.0.391759759804.issue1683368@psf.upfronthosting.co.za>
2014-05-28 22:57:52gvanrossumlinkissue1683368 messages
2014-05-28 22:57:51gvanrossumcreate