[Python-Dev] PEP 252, PEP 253 and jython issues

[Guido van Rossum]

> 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/)