"Phillip J. Eby" <pje@telecommunity.com> writes:
* Interfaces may be read as documentation, because there is no behavior in the way. All that's there is just signatures and docstrings.
* It's easier to see what is *really* the expected interface, as opposed to an accident of implementation.
ABC's have a tendency to start out clean, but then accrete a bunch of implementation junk over time. With a pure interface, there's no tempation to do it, since there's absolutely no benefit to putting any implementation in the interface.
Interesting - wouldn't that stop them from being ABCs at that point? The only thing in my ABCs with respect to implementatation is the "raise NotImplementedError" for each method. Basically the same as the example in the PyProtocols documentation. I really hadn't envisioned ever adding anything other than that (after all, then it wouldn't be an "Abstract" base class), although I suppose I could see how someone might let something slip in.
So, if you are creating a framework of any significance, your users will in all likelihood thank you for using the pure style instead of the ABC style, unless you have exceedingly strong discipline as far as being able to keep implementation out of the ABC, or are separately specifying/documenting the expected behavior anyway.
Speaking of documentation and convenience for users, it's nice when inheriting from an ABC interface lets tools such as epydoc automatically inherit the documentation strings for the methods as well for classes that implement them. Otherwise, do you find yourself duplicating docstrings in the classes providing the interfaces, or how do you handle that aspect of things. I notice that a lot of the Twisted documentation makes use of the links (such as the L{} epydoc notation) to cross-reference the appropriate interface for the concrete classes that implement the interfaces, whereas the ABC approach would seem to simplify that aspect of things. -- David