<br><div><span class="gmail_quote">On 3/8/07, <b class="gmail_sendername">Bill Janssen</b> <<a href="mailto:janssen@parc.com">janssen@parc.com</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There's an incomplete wiki page about a possible factoring of types at<br><a href="http://wiki.python.org/moin/AbstractBaseClasses">http://wiki.python.org/moin/AbstractBaseClasses</a>.</blockquote><div><br>The one thing that I have been unable to figure out (from that page, the python-dev/python-3000 messages on the subject and talking with Guido) is why ABCs are better than explicit interfaces like Twisted and Zope use. I think mixing in abstract baseclasses in the normal inheritance tree is a mistake, and if you have a separate tree, you really just have interfaces. I can think of a half dozen nagging warts that will pop up with using ABCs instead of interfaces, most of which I already griped to Guido about (but failed to convince him.)
<br><br> - You can't take a third-party object, not participating in the ABC/interface craze, and say 'it inherits from this ABC' (which you can do for interfaces.)<br> - If the abstract classes hold actual attributes (as is the suggestion, as far as I can tell) rather than be completely empty, they can end up in the middle of the inheritance tree and mess up MRO.
<br> - If the abstract classes are really completely empty, you need another mechanism for figuring out what a particular abstract class entails.<br> - You can't define *any* 'magic' on the abstract classes, things that are supposed to work on ABCs only, because any inherited class will of course automatically inherit the magic. If you use a magic metaclass for ABCs that works around that, people 'implementing' classes with their own metaclass will have to remember to subclass their metaclass from the ABC-magic-metaclass.
<br> - Because of the no-magic thing, you can't have the ABC do useful things, like asking it to verify if an implementation class has the right attributes or whether it can find an adapter for one ABC to another.<br>
- You can't un-inherit an ABC, ever. You can't inherit from a particular class to get some free implementation, but provide a slightly different (conflicting) interface. (Alright, probably not realistically a problem, but still.)
<br></div> - Mixing interface-definition and implementation like that makes it hard for new programmers to pick up the difference. It will be harder to explain the difference between 'dict' and 'Mapping' when they are both in the list of bases. How can you tell one from the other?
<br><br>As far as I can see, there is tremendously little difference between ABCs and interfaces, at least the way Guido explained his ideas for ABCs to me. The entirely Wiki page can be turned into a list of interfaces with a few textual edits. The only difference is that ABCs nestle in the normal MRO, which, in my eyes, is not a benefit at all. So... what's the actual benefit of ABCs over interfaces?
<br></div><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org">thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!