[Python-Dev] PEP 447: hooking into super() attribute resolution

[Guido van Rossum]

On Mon, Jul 15, 2013 at 8:12 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> I've posted a new update of my proposal to add a way to override the attribute resolution proces by super(). I've rewritten the PEP and implementation based on feedback by Steve Dower.
>
> In the current edition of the proposal the hook is a method on the type, defined in a metaclass for types. A simple demo:
>
>     class meta (type):
>         def __locallookup__(cls, name):
>             return type.__locallookup__(cls, name.upper())
>
>     class S (metaclass=meta):
>         def m(self):
>             return 42
>
>         def M(self):
>              return "fortytwo"
>
>     class SS (S):
>         def m(self):
>             return 21
>
>         def M(self):
>            return "twentyone"
>
>     o = SS()
>     print("self", o.m())
>     print("super", super(SS, o).m())
>
> The last line currently prints "super 42" and would print "super fortytwo" with my proposal.

I would suggest adding that motivation to the PEP, since you clearly
thought it was necessary to get people to consider your proposal. :-)

> A major open issue: the __locallookup__ method could also be used for normal attribute resolution, but that probably causes issues with attribute caching (see the PEP for details).  I haven't worked out yet if it is worthwhile to tweak the proposal to fix the caching issues (even though the proposal currently says that PyObject_GenericGetAttr will use the new method). Fixing the caching issue definitly would help in my primary use case by reducing code duplication, but might end up making the API unnecessarily complex.

Hm. It looks like the functionality you actually want to hook into is
in _PyType_Lookup().

I think that in this case the PEP's acceptance will be highly
correlated with your ability to produce an actual patch that (a)
implements exactly the functionality you want (never mind whether it
matches the exact API currently proposed), and (b) doesn't slow down
classes that don't provide this hook.

Other than that, I think that it's a laudable attempt at generalizing,
and I hope you solve the implementation conundrum.

-- 
--Guido van Rossum (python.org/~guido)