[Python-Dev] PEP 447: add type.__locallookup__

[Ronald Oussoren]

On 19 Sep, 2013, at 12:12, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 
> On 19 Sep 2013 20:00, "Paul Moore" <p.f.moore at gmail.com> wrote:
> >
> > On 19 September 2013 10:32, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
> > > The first time a method is called the bridge looks for an Objective-C selector
> > > with the same name and adds that to the class dictionary. This works fine for normal
> > > method lookups, by overriding __getattribute__, but causes problems with super:
> > > super happily ignores __getattribute__ and peeks in the class __dict__ which may
> > > not yet contain the name we're looking for and that can result in incorrect results
> > > (both incorrect AttributeErrors and totally incorrect results when the name is
> > > not yet present in the parent class' __dict__ but is in the grandparent's __dict__).
> >
> > As an alternative approach, could you use a custom dict subclass as
> > the class __dict__, and catch the peeking in the class __dict__ that
> > way? Or is this one of those places where only a real dict will do?
> 
> Even Python 3 doesn't let you control the *runtime* type of the class dict, only the type used during evaluation of the class body.

Changing the class dict type from C is easy enough, but as you wrote below doing this gives you an interesting experience. Changing PyDict_* to call the subclass implementation of the corresponding slot would be easy enough, but that changes the behavior of a core CPython API and I wouldn't look forward to auditing the CPython code base to check if such a change is safe (let alone all other extensions). Some code will use the PyDict_* API instead of the abstract API because the former is faster, but at least some callers for PyDict_GetItem will do this to explicitly get the base class implementation.

Ronald


> 
> I've played with changing that - it makes for a rather special interpreter experience :)
> 
> Cheers,
> Nick.
> 
> >
> > Paul