The UI Delegate classes, located in the Delegates module, use multiple inheritance, being derived from both a View and a Controller. This means they combine functionality from both into a single class: not only does it specify the interface, it also handles the widget signals. It's the "can't beat them, join them" solution to the V+C coupling problem, and it's used in Swing, MFC and Bakery, a C++ framework for GTK+.
The Delegate class is a combination of BaseView and BaseController. You can use it to create your interface programatically and then hook up handlers to it, just like you would do to individual views and controllers. A very simple (yes, I too get bored of hand-coding PyGTK widgets) example follows, found in the distribution as examples/Simple/simple.py:
As you can see, the Delegate was the only class we needed to inherit from and instantiate. This makes the amount of infrastructure code go down significantly, and most single-window applications (and individual dialogs in multi-window applications) can be implemented with single Delegate and GladeDelegate subclasses. As an example for using the GladeDelegate, below is a third version of our temperature conversion application, examples/Faren/faren3.py:
As you can see, using the delegates makes a lot of sense in many cases: the view and controller split isn't essential, and you can end up with a lot less code with the same functionality at no reduced maintainability or readability, which is what we are aiming for. For larger applications, or apps where a lot of very unusual functionality is required, it may still make sense to use separate Controllers and Views, but for normal development, stick to delegates; they simplify things.
Note that there is also a SlaveDelegate, which works like a normal SlaveView with an attached Controller. The next section describes an important subclass of SlaveDelegate, the CListDelegate.