[Guido]
I haven't given up the hope that inheritance and interfaces could use the same mechanisms. But Jim Fulton, based on years of experience in Zope, claims they really should be different. I wish I understood why he thinks so.
[Ping]
If i may hazard a guess, i'd imagine that Jim's answer would simply be that inheritance (of implementation) doesn't imply subtyping, and subtyping doesn't imply inheritance.
Well, yes, of course. But I strongly believe that in *most* cases, inheritance and subtyping go hand in hand. I'd rather invent a mechanism to deal with the exceptions rather than invent two parallel mechanisms that must both be deployed separately to get the full benefit out of them.
That is, you may often want to re-use the implementation of one class in another class, but this doesn't mean the new class will meet all of the commitments of the old. Conversely, you may often want to declare that different classes adhere to the same set of commitments (i.e. provide the same interface) even if they have different implementations. (A common situation where the latter occurs is when the implementations are written by different people.)
Nevertheless, these are exceptions to the general rule.
Agreeing on an ontology seems the hardest part to me.
Indeed. One of the advantages of separating inheritance and subtyping is that this can give you a bit more flexibility in setting up the ontology, which may make it easier to settle on something good.
Really? Given that there are no inheritance relationships between the existing built-in types, I would think that you could define an ontology consisting entirely of abstract types, and then graft the concrete types on it. I don't see what having separate interfaces would buy you. But perhaps you can give an example that shows your point? --Guido van Rossum (home page: http://www.python.org/~guido/)