[Python-Dev] PEP 252, PEP 253 and jython issues
Guido van Rossum
Fri, 24 Aug 2001 08:54:10 -0400
> 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
> 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
I don't expect this to be a common use pattern though (famous last
> A natural way to design PEP252, and PEP253 for Jython would
> be start to start from the equation:
> object = org.python.core.PyObject
> 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
> 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/)