[PyQt] thoughts about dip interfaces and python abstract base classes

[Darren Dale]

Hi Phil,

On Mon, Mar 14, 2011 at 5:11 AM, Phil Thompson
<phil at riverbankcomputing.com> wrote:
> On Sun, 13 Mar 2011 15:01:53 -0400, Darren Dale <dsdale24 at gmail.com>
> wrote:
>> I've been learning about python's abstract base classes at
>> http://www.python.org/dev/peps/pep-3119/ and
>> http://docs.python.org/py3k/library/abc.html . The PEP mentions that
>> there is considerable overlap between ABCs and interfaces, and I'm
>> rereading the dip documentation on interfaces now. If I understand
>> correctly, dip's "implements" decorator is similar (perhaps based on)
>> python's abstract base class "register" class method. Is it ever the
>> case that dip classes actually subclass a dip interface, as python
>> classes would subclass one or more abstract base class?
>
> No (as in it's technically possible but you shouldn't do it). dip
> interfaces can be sub-classed to created more specific interfaces, but the
> only link to an implementation of the interface should be via the
> @implements or @adapt class decorators.

Thanks for the clarification. I found this portion from the dip
documentation slightly confusing:

"In many ways using the implements() decorator is similar to
sub-classing the interface"

... then there is some discussion of the strengths and weaknesses of
subclassing vs using "implements", so it wasn't clear to me that
subclassing was actually discouraged. (Although, in context, there are
no examples where an concrete implementation actually subclasses an
interface).

[...]
> It comes down to a personal philosophical choice - I much prefer
> interfaces to ABCs. The problem with ABCs is that they encourage putting
> the interface definition in the same place as a default implementation.
> From an architectural point of view I strongly believe that they should be
> kept separate.

I was a bit disappointed when I read a couple years back that PEPs 245
and 246 were being rejected in favor of ABCs. I think I understand the
patterns a little better now, and it seems the intent of ABCs is
nearly identical to that of Interfaces. For example, PEP 3119 lists
ABCs for containers and iterators which actually define the interfaces
for Hashable, Iterable, Sized, Container, etc. The main differences
(apart from syntax) seem to be that subclasses of an ABC can access a
default implementation via the use of super(), while implementations
of an Interface cannot. The ABC PEP mentions: "This could be useful as
an end-point for a super-call in framework using cooperative
multiple-inheritance", but I see your point about how this could lead
to misuse of the Interface pattern. Otherwise, there is such
considerable overlap (when an ABC is truly abstract) that Interface
could actually be considered an extension of ABCs that supports
adaptation.

> Interfaces have their own problems of course - mainly the need to repeat
> the interface definition in an implementation. With Traits, for example,
> an
> implementation must contain a copy of the interface's attributes and
> methods - which is error prone. dip is better because you don't have to
> repeat the definition of the interface's attributes - they are injected
> automatically into the implementation - but you still (for the moment
> anyway) to have to repeat the interface's methods.

I guess it would be necessary to repeat the methods either way,
because they are abstract, right?

At any rate, I found it interesting that, in python, ABCs (containing
only abstract methods) and Interfaces are so similar that it would be
possible to embrace the Interface philosophy and pattern by extending
abstract base classes. It leaves me with a gut feeling that there
could potentially be some long-term benefits to dip by basing
Interface on this new fundamental aspect of the python standard
library.

Thanks for the feedback. Its always a pleasure.

Cheers,
Darren