> Yes, I'm thinking furiously. See if I can keep up with you. :-) > GvR > A safe rule would be to require that all Python classes in a > GvR > given inheritance graph should derive from the same C/Java class. I > > > That would mean that all C/Java behaviour is always only at the top > > of the mro, right? > > > > I had the same idea because this would make my life easier. > > > > A problem: some of the Zope porters reported that there are classes > > that inherits from more than a single ExtensionClass in Zope :-( > > don't know if that is true. (**) > Oops, this is already a problem with the actual best_base rule, > I don't know if my reinterpretation is OK, but doesn't it > basically states that all C types subclassed by a new C level class > should be in a subtyping relationship that means: > > with > A isa list isa object > B isa special_list isa list isa object > C isa object > > class D(A,B,C): ... is OK > > but with > > Z isa Cbadboy isa object > > then class D(Z,A) isn't allowed. Correct. You can't multiply inherit from two types that have a different structure layout. The C code must be able to safely cast a PyObject* to a PyListObject* or a Cbadboy* and if those don't have the same structure it's not safe. The implementation restricts this pretty effectively I believe. (You can't multiply inherit from list and dictionary, but you can from list and xxsubtype.spamlist.) > but if that is already *not* *a* *problem* then I think the rule could > be not that bad ... What do you mean by "already *not* *a* *problem*"? I hope "it is already forbidden". And "the rule" refers back to my proposal quoted above with "GvR >", right? --Guido van Rossum (home page: http://www.python.org/~guido/)
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