Glyph Lefkowitz <glyph@twistedmatrix.com> writes:
On Thu, 2004-02-26 at 19:17, Phillip J. Eby wrote: (...)
I have considered it. Unfortunately, it runs counter to one PyProtocols use case I'd like to support, which is the ability to use an abstract base class as a protocol. That is, somebody should be able to instantiate non-abstract subclasses of a protocol. (...)
Considering that this is a rather uncommon use-case, can it be made into the non-default Interface class? Or an attribute/feature of the default one, such as
Since neither Twisted, nor the default interfaces defined in PyProtocols use the ABC approach, I've been curious about this since I started using these packages. Why aren't more interfaces defined in the ABC style? When Ifirst started defining some interfaces in my project with PyProtocols, and had to make the choice between an ABC interface and a documentation interface, ABC seemed to me as more desirable. I'll admit to almost wishing I didn't have the option at the time, because to be true I didn't really have a good idea of the pros and cons so it was sort of one of those uncertain feeling decisions (sort of like picking a Python web or application framework :-)). What finally turned it for me was that the ABC approach gave me a clean failure if the implementation object didn't really fulfill the interface, as in forgot to override a method or declare an attribute. Perhaps it was because the first set of things I was defining were interfaces for specific components I was building, so there was a natural 1:1 mapping between interface and initial objects. I suppose as my work grows I'll find more cases where the interfaces are just portions of an object, but wouldn't it still be preferable to just use MI from multiple interfaces to get the same failure handling? Obviously, the ABC approach doesn't seem to be adopted by Twisted or PyProtocols (at least for its official interfaces) themselves, but I haven't really seen references to advantages of the non-ABC variant. -- David