New submission from Ronald Oussoren: 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. ---------- components: Interpreter Core messages: 190905 nosy: ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: super vs. someclass.__getattribute__ type: behavior versions: Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18181> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com