Re: [Jython-dev] nightmare: PEP 252, PEP 253 and jython issues

[Samuele P. <pe...@in...>]

Hi. I agree with your considerations, in the discussion with Guido
I was trying to understand how serious he was about the new mro
at C level and with the very basic types.
It seems that the semantics of Python will have a bit more holes
and that Guido's philosophy is: there are some rules for the rest
let it be ... so we have some space to take *our*
decisions.

>
> [SP]
> >A natural way to design PEP252, and PEP253 for Jython would
> >be start to start from the equation:
> >
> >object = org.python.core.PyObject
>
> Conceptional I agree, but do you also think that a simple
>
>    class A(object): pass
>
> should create a true subclass of PyObject? That would add the proxy
> overhead to all python classes, wouldn't it?
No, in any case java subclassing from Jython as it is, would not do the trick.
The point is more that if someone subclasses PyObject in Java we should treat
that as a type and not as a simple JavaClass. I think it is important to
support
 that at least.

What class A(object): pass should do is still unclear to me.  To be honest
we can have probably a lot of freedom about what that produces but
the point is what then A() should deliver.
The other main  points are:
type = ?
object = ?
both at Jython and internal level.

Another problem is that we should decide how the whole new type stuff
should interact with Jython level Java subclassing.

>
> [SP]
> > ..., I'm worried about this scenario
> >
> > A subclasses object and redefines __getattr__
> > B subclasses list
> >
> > then class C(B,A): ...
> >
> > will have the following mro:
> >
> > C B list A object
> >
> > [snip]
> >
> > now A is in between list and object: what is the right thing here?
>
> That was a very good catch (bravo), but we should ignore the problem for
> the builtin types like list and dictionary. A flexible mro like this
> that depends on an inheritance graph defined later (maybe in another
> module) should not be followed by our builtin types.
>
> After all, "B isa list isa object". There is no A in that static linage,
> no matter what GvR think python2.2 should do.
Yes, it seems  that for Guido we can use simple direct Java
subclassing for Java level Jython types, but if that doesn't
work well, we cannot call him guilty <wink>.

> The restrictions that GvR put in place when subclassing dictionary make
> subclassing of types highly overrated. It doesn't seem to have much
> practical purpose.
Yup, but at the C (our Java) level his philosophy is more: no restrictions
and is up to the programmer to play safe.

>
> > In Jython codebase hypothetically but possibly list could contains
> > calls like:
> >
> >   __getattr__(...)
> >   and super.__getattr__
>
> Which should 100% be resolved as normal java virtual method calls.
>
> The effect of any such decission that we make, may mean that jython
> types are a little less flexible than their CPython counterpart. I can
> live with that.
My impression has been that at least the built-in will remain
inflexible also on CPython side, that Guido has no intention
to specify how that much flexibility should be used, so I presume
things pratically will remain inflexible or ... caothic.

>
> [SP] *bad-guy-java*
> > 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.).
>
> Is this more of a problem in 2.2 than it is now? OTOH I can see the
> problems if all python classes subclass PyObject, but I can't see that
> as a way forward.
mmh, no PyObject and the built-in types are not that big problem, we
can special case and are under our control and their hierarchies are
shallow, the problem is more if someone creates a deep hierarchy
of types (PyObject subclasses) in Java:

C isa B isa A isa PyObject

because in principle if they all override __getattr__ the descr semantic
says that we should extract the behaviour at all levels.

There are many issues, but the major problem is not that we can't find
solutions but that no good solution would probably be a quick hack.

regards, Samuele Pedroni.