On Sat, Mar 10, 2007 at 06:09:40PM +0000, Jonathan Worthington wrote: : It's a confusing problem, for sure. I've thought about it, but as of yet : have no good answers. I don't think forbidding having classes with : different MROs in a single hierarchy is the answer, because that loses a : lot of the inter-language stuff that we want. : : One option is to say that a class cannot have a different MRO than its : parent class, so if it's a conflict we take the parent class's chosen : MRO. That makes classes you inherit from work. It may be confusing for : people subclassing them in another language, but on the other hand you : have explicitly stated that you are pulling in a class from another : language (since the language name is in the namespace), there's a clue : about what you should expect. Of course, once you get three languages : down the tree, you have no clue which one your MRO is coming from just : by glancing at the import line. Which means in general you don't know. Hmm. : : I can't really think of any other options at the moment, or at least : anything that's even vaguely sane.
I look at it this way. When you want to find the ancestors of a particular object, you ask its metaobject for a list. That metaobject may either choose to generate the entire list itself or delegate some of that generation either to the ancestors in question or to some cooperative system such as C3. But you can't tell the metaobject which of those approaches it should choose. That's what's meta about it. It's supposed to tell you how, not you it how. Larry
