David> It sounds to my C++ ear like you're trying to make this David> analogous to runtime polymorphism in C++. I think Python's David> polymorphism is a lot closer to what we do at compile-time in David> C++, and it should stay that way: no inheritance relationship David> needed... at least, not on the surface. Here's why: people David> inevitably discover new type categories in the objects and David> types they're already using. In C++ this happened when Stepanov David> et al discovered that built-in pointers matched his mental David> model of random-access iterators. A similar thing will happen David> in Python when you make all numbers inherit from Number but David> someone wants to impose the real mathematical categories (or David> heck: Integer vs. Fractional) on them. David> What Stepanov's crew did did was to invent iterator traits, David> which decouple the type's category from the type itself. Each David> category is represented by a class, and those classes do have David> an inherticance relationship (i.e. every random_access_iterator David> IS-A bidirectional_iterator). In other words, there *is* an inheritance relationship in C++'s compile-time polymorphism, and iterator traits are one way of expressing that polymorphism. So we have two desirable properties: 1) Guido's suggestion that interface specifications are close enough to classes that they should be classes, and should be inherited like classes, possibly with a way of hiding that inheritance for special cases; 2) Dave's suggestion that people other than a class author might wish to make claims about the interface that the class supports. I now remember that in one of my earlier messages, I said something related to (2) as well. Is there a way of merging these two ideas? -- Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark