Super() walks the MRO and looks for the looked-up attribute in the __dict__ of types on the MRO. This can cause problems when classes implement __getattribute__: a class on the MRO can implement a method that super() won't find because it isn't in the class __dict__ (yet).

I'm running into this with PyObjC: the __dict__ for the Python proxies for Objective-C classes are filled lazily (*) by tp_getattro (__getattribute__ in Python) to speed up the bridge and because ObjC is almost as dynamic as Python and methods might appear during runtime (without there being a hook for detecting such changes).

A possible solution to this:

* Add a tp_getattro_super (**) slot to PyTypeObject, with the 
  same signature as tp_getattro, but that only looks at this particular
  class (as opposed to tp_getattro that walks the entire MRO and looks
  in the object's __dict__)  (***)

* The tp_gettro of super calls tp_getattro_super of types of along the
  MRO when that slot is not NULL, and uses the current implementation
  (look in tp_dict) when the slot is NULL.

Would such a change be acceptable?

Open issues:

* Does the new slot get exposed to Python code 
  (and if so, under which name)?

* Should PyObject_GenericGetAttr use the new slot as well?


Footnotes:

(*) The current release of PyObjC (2.5) eagerly tries to keep the proxy class __dict__ up to date, an upcoming major release will be as lazy as possible to speed up the bridge. The problem can with some effert be triggered with PyObjC 2.5, and triggering it is easy in the upcoming major release

(**) Or some better name

(***) I'm being very sloppy in my use of terminology here, hopefully my proposal is clear enough anyway.