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

[Samuele Pedroni]

Thanks for the answers, I'm happy the questions were parseable,
Here are some comments, I think they may be meanigful also for CPython

> > 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.
I overlooked this, I think we can implement that also in Jython.

An important point: should that be the only way to use a Python level
exposed and overridable method from C code, is that left
to the programmer ?

The problem is that with the new mro possibly independently C defined 
things  get interleaved with Python level code, 
so I imagine that the effect should be a bit disciplined ...

I saw that list_ass_slice calls list_slice directly, is that OK?

> > And how can safely CSpecialList invoke a  "super" behaviour, it is saf
> > 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 :-).

But it is certainely a pattern that a writer of Jython types would expect
to use. The problem is still that C/Java stuff with the new mro
get interleaved with Python level behaviour.

IMHO you would better discipline this and also the above point <wink>.
I don't know if there is some GUI toolkit that implement inheritance
using C and not some language enforcing OO like C++, etc.

Other OO languages like Smalltalk, Self, or Java allow only to define
primitives or single methods to add lowel-level functionality,
they don't try to allow subtyping at that level, the previous
scenario in Python where you could define just opaque types,
and in particular your C code never/normally got interleaved with Python
 behaviour was on that line.

At worst you could say that you allow subtyping but not code sharing,
but then even a C method for an object should be very careful using
another overridable method of the very same object.

OK you could say: that's C level, everybody should care for herself,
but with Java we cannot do the same.

> > 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 :-).
No it is ruled out at Java level, not Jython level.
But it is not also ruled out in CPython at C level?

> > 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.
see above.

>  I propose that you just try to live with
> this.
Related e.g. to Zope porting projects there have been a lot of pressure
on jython-dev regarding how to code new types and metaclasses,
A Jython type writer expect to be able to use Java naturally (i.e. use inheritance),
for that, so the situation isn't that easy,
is not even easy with the current codebase, because given the new mro one can even
put some Python behaviour between:

PyList PythonLevelCode and PyObject :-( (*)

>  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
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. (**)

> don't know if we should enforce this or just warn about it in the
> documentation.
It would make our (jython-dev) life easier and avoid some impredictable
 problem even with CPython and code sharing,
  but see previous note (**)

>  I don't want to force you to call a cooperative super
> method at the Java level -- it would be very slow, I suspect...
Yes ... very slow and we would have to use that also at the very core
of the hierarchy, see (*)
but the problem is more complicated, in Java given three classes

C extends B extends A
and a method m
C.m overrides B.m overrides A.m

there is not direct way (even using reflection) 
to apply B.m behaviour to a C object, unless
the programmer has left some hook in C using super
or in B ( a method B_m e.g.).

... complicated :(

regards.