[Python-ideas] [Python-Dev] python and super

[Nick Coghlan]

On Mon, Apr 18, 2011 at 1:25 AM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> On 17/04/2011 14:09, Nick Coghlan wrote:
>> So if the only information you have available is D's MRO (which is the
>> current situation for super()), then you *don't know* whether B is C's
>> parent, sibling or both - the calculation of the MRO discards too much
>> detail about the class hierarchy.
>>
>
> But given that the mro contains the actual classes, *all* the information is
> available at runtime. (If a call to a method of B terminates the chain then
> super would be able to know what the base classes of B are by looking at B -
> even if that isn't expressed directly in the mro.)

But super() is out of the picture by the time B returns - it's just an
object, it has no control over what happens when its methods return.
There's no overarching object with a view of the whole method chain,
just a series of object constructions and method calls:

obj.__mro__ == D, C, B, A, object

obj.method()
--> D.method(obj)
----> super(D, obj).method() # (aka C.method(obj))
------> super(C, obj).method() # (aka B.method(obj))
--------> super(B, obj).method() # (aka A.method(obj))
----------> super(A, obj).method() # (aka object.method(obj))

How does the caller of super(D, obj).method() know whether or not
super(C, obj).method() was called any more than the caller of
C.method(obj) knows whether or not B.method(obj) was called?

>> Creating a dynamic MRO for every single method call
>
> It is *only* needed where you are mixing super calls with non super calls in
> the presence of multiple inheritance. So not for every method call.

Then why build it into super() at all? Prove the concept by going back
to old-school super style and pass in the class reference explicitly
and create a dynamic MRO based on removal of your parent classes but
not your siblings. I just don't think it is possible to solve this as
simply as you appear to believe. If you can produce a working
prototype that actually has acceptable performance, is backwards
compatible with current cooperative super() code then I'll be happily
proven wrong, but the entire concept currently seems to be based on an
idea of iterating over the MRO in a way that *doesn't actually
happen*.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia