[Python-Dev] type categories

[Andrew Koenig]

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