[responding to a thread on python-dev regarding the type/class
unification in PEP252 and PEP253. I'm writing it here because I need a
little time to get my head around the issues]
>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?
I have a feeling that we should treat object specially when used as a
superclass. Similar should calls to default behaviour in object be
treated as a special situation.
> ..., 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
> 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.
The restrictions that GvR put in place when subclassing dictionary make
subclassing of types highly overrated. It doesn't seem to have much
> In Jython codebase hypothetically but possibly list could contains
> calls like:
> 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.
> 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.