Hi Phil, On Mon, Mar 14, 2011 at 5:11 AM, Phil Thompson <[email protected]> wrote: > On Sun, 13 Mar 2011 15:01:53 -0400, Darren Dale <[email protected]> > 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 _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
