> OK, here is my major concern > > Given the following three types subclassed in Pyhon: > class A(CSpecialList): ... > > class B(list): ... > > class C(A,B): ... > > where CSpecialList is a subtype of list written in C. > > Now the old mro would be: > > C A CSpecialList list object B list object > > that translate to the new mro > > C A CSpecialList B list object Correct. > The question is it possible for CSpecialList for the code that define > for example sq_ass_slice to use sq_slice code in a safe manner? > (AFAIK listobject does something similar) I'm not 100% sure I understand this question, but CSpecialList can certainly override sq_ass_slice. Then, if it wants to call self.__slice__ (in Python terms) it could call obj->ob_type->tp_as_sequence->sq_slice -- this would call C's obj->ob_type->tp_as_sequence->__slice__ if it had one. > And how can safely CSpecialList invoke a "super" behaviour, it is safe > for it to refer to the behaviour offered by list. In principle > given the mro e.g. a __getslice__ redefined in B should shadow > such a behaviour? I don't know if cooperative super calls are possible at the C level. I certainly didn't define an API for this. I didn't define a Python level API either, but I know how to o it and it can even be coded in Python. Hm, I guess that makes it a theoretical possibility at the C level. I don't expect this to be a common use pattern though (famous last words :-). > A natural way to design PEP252, and PEP253 for Jython would > be start to start from the equation: > > object = org.python.core.PyObject Yes. > then it is necessary to build a class that truly correspond to the type > metatype, actually jython fakes using the metatype used for Java Classes for > that. > > It would make sense to use Java subclassing to implement > type subclassing, at least at layout level this does not clash with > the multiple inheritance rule in best_base. So you would rule out multiple inheritance of types? Fine with me, but you may regret this a few yearsfrom now (when we all code multiple inheritance all the time :-). > And actually is also how Jython now works: for example > PyList extends PySequence that extends PyObject. And that's how it should be. > But than there is the issue of method resolution order: from the viewpoint > of Python code we can implement anything, not that easy ... > > But the at the Java level, where we construct types, the codebase uses the > normal single inheritance of java and the codebase is full of super.foo > invocations and of methods that cross-call each other (potentially overriden) > versions, and this happen also for behaviour that correspond to the slots/ > __foo__ special methods of CPython. > > That's why the two questions are important? I see. CPython doesn't have this problem (yet) because it doesn't use inheritance at the C level. I propose that you just try to live with this. A safe rule would be to require that all Python classes in a given inheritance graph should derive from the same C/Java class. I don't know if we should enforce this or just warn about it in the documentation. I don't want to force you to call a cooperative super method at the Java level -- it would be very slow, I suspect... --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