[Python-Dev] Hooking into super() attribute resolution

[Ronald Oussoren]

On 8 Jul, 2013, at 17:19, Steve Dower <Steve.Dower at microsoft.com> wrote:

> The only real advantage is a simpler signature and more easily explained use (assuming the person you're explaining it to is familiar with metaclasses, so most of the hard explaining has been done).

The signature is as complex as it is to be able to call descr.__get__ with the correct arguments. I ended up with the current signature when I added __getattribute_super__ to object and removed the tp_dict peeking code from super's tp_getattro.

A way to get a simpler interface again would be a method that returns an attribute *without* performing calls to descr.__get__. That could then be used for both __getattribute__ and super.__getattribute__, instead of peeking in a class' dictionary. I must admit that I haven't thought about the ramifactions of this (both functionally and performance wise).  This might end up being easier to explain: both normal attribute resolution and super's resolution would end up using the same mechanism, with the differences being that super doesn't begin resolution at the start of the mro and ignores the instance __dict__.  The disadvantage is introducing a new way to affect attribute resolution (do I use "__getattribute__" or this new method?). 

The new interface would be something like:

    @classmethod
    def __getlocalname__(cls, object, name):
        pass

Or as you mentioned later as a __getlocalname__ method on the metaclass. The "object" argument wouldn't be necessary to reproduce current functionality, and isn't necessary for my usecase as well, but a hook for attribute resolution on an instance that doesn't have access to that instance feels wrong.

> 
> I'm still not sure that this isn't simply a bug in super. If the superclass's metaclass provides a __getattr__ then it should probably use it and abandon it's own MRO traversal.

I'd have to think about this, but on first glance this would mean a change in the semantics that a metaclass' __getattr__ currently has.

> 
> I still haven't thought the edge cases through, and it seems like there'd be some with that change, so that's where __getattribute_super__ comes in - super can call it without abandoning its MRO traversal.
> 
> AFAICT, the difference between that and __getlocalattribute__ is that the latter would be implemented on a metaclass while the former takes extra parameters. I think this functionality is advanced enough that requiring a metaclass isn't unreasonable.

I'm not necessarily oppossed to a solution that requires using a metaclass, I already have metaclasses with custom metaclasses in PyObjC and this wouldn't add that much complexity to that :-)

Ronald