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

[Samuele Pedroni]

[GvR]
>
> > now A is in between list and object: what is the right thing here?
> 
> Just say that this is what happens.  The MRO is inconsistent in this
> case.
> 
> > I don't expect or invite users to do that, but your rules allow A to
> > end up in that position in the mro, your philosophy seems to be
> > this is thin ice and so let it be ... 
> 
> Exactly.
I wish I would not feel uneasy with that <wink>

> 
> On the third hand, if a C programmer *wants* to write a class with the
> proper cooperative super calling, they can do so, it's just a bit
> clumsy.  Should I provide a C API to make this easier?  I doubt that
> it will be used much.  If there's demand, it can be added later.
I hope there will not be.


GvR> I don't think such subclasses
GvR> should be used in complex multiple inheritance lattices.
> 
> > Better to enforce that?
> 
> Why?  I can think of situations where you have a MRO like this:
> 
>   C list B object
> 
> but where B doesn't override anything that list might use.  In fact,
> this is the typical mix-in situation.  I don't want to forbid this.

OK, I see. (*)


GVR> So enforce it and see how it turns out in practice.
> 
> > It's probably the best solution, at least for Jython,
> > and could even make sense for CPython (see above points)
> 
> Good.  We seem to agree.
Yup but I see your point (*) so probably I can't.

[me] *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.).

> 
> I hope this discussion so far has been helpful -- I have to pack for
> my trip and will soon be off to San Francisco until next Wednesday.
> 
Yes it was, thanks but
I overlooked a central point, namely *bad-guy-java*

I fear, because of it, we have to code all the built-in types this way,


class SpamType {

... SpamTypes__foo__ { ...
}

... __foo__ { }

}

Or find other slower ways, otherwise no descrs for them 

A nightmare :-(

regards.