On 14 Sep, 2013, at 8:30, Nick Coghlan <ncogh...@gmail.com> wrote: [... interesting text that I'll respond to later ...]
> > So my proposed name is based on the idea that what Ronald is after > with the PEP is a hook that *only* gets invoked when the interpreter > is doing this hunt for descriptors, but *not* for ordinary attribute > lookups. I'll describe the usecase that led to my proposal. I'm amongst other the primary author (and sole maintainer) of PyObjC, which is a bridge between the Python and Objective-C class/object models. PyObjC defines a proxy class for every (Objective-C) class in the Objective-C runtime and when an Objective-C object is made available to Python code the PyObjC bridge creates a proxy object that is an instance of this proxy object. This is simular what wxWidgets or PyQt do, but everything is done at runtime by introspecting the Objective-C runtime. 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__). The current release of PyObjC "solves" this problem by providing a subclass of super (objc.super) that should be used instead of the builtin one and that works, although the implementation of this class is a gross hack. Users's of PyObjC are currently oblivious of the problem because I sneak in objc.super as a module's globals()['super'] when it imports PyObjC in the currently prefered way (which is using *-imports: "from Cocoa import *"). I'm currently migrating to deprecating *-imports because those are bad for the usual reasons, but also because framework binding modules are huge and using plain imports makes it possible to delay, and often even avoid, the cost of loading stuff from the framework binding modules. That switch will however make the problem of using __builtin__.super extremely visible for PyObjC users. That, and the implementation hack of objc.super, is why I started looking for a way to cleanly provide a way to hook into the attribute resolution for super(), which ended up as PEP 447. Note that the description is slightly simplified from what PyObjC reall does, Objective-C can (and does) have class and instance methods with the same name, because of that all PyObjC classes have a meta class of the same name and that makes everything even more complicated, but that should not be important for the previous description. PyObjC also enables implementing Objective-C classes in Python, but that's also not relevant for this discussion. Ronald _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
