[Python-Dev] type categories

Andrew Koenig ark@research.att.com
26 Aug 2002 11:57:31 -0400

Guido> Well, yes, of course.  But I strongly believe that in *most* cases,
Guido> inheritance and subtyping go hand in hand.  I'd rather invent a
Guido> mechanism to deal with the exceptions rather than invent two parallel
Guido> mechanisms that must both be deployed separately to get the full
Guido> benefit out of them.

I think there are (at least) three important kinds of problems, not just two.

        1) You want to define a new class that inherit from a class
           that already exists, and you intend your class to be in all
           of the categories of its base class(es).  This case is
           probably the most common, so whatever mechanism we adopt
           should make it easy to write.

        2) You want to define a new class that inherits from a class
           that already exists, but you do *not* want your class to be
           in all of the categories of its base classes.  Perhaps you
           are inheriting for implementation purposes only.  I think
           we all agree that this case is relatively rare--but it is
           not completely unheard of, so there should be a way of
           coping with it.

        3) You want to define a new type category, and assert that
           some classes that already exist are members of this category.
           You do not want to modify the definitions of these classes
           in order to do so.  Defining new classes that inherit from
           the existing ones does not solve the problem, because you
           would then have to change code all over the place to make
           it use the new classes.

Here is an example of (3).  I might want to define a TotallyOrdered
category, together with a sort function that accepts only a container
with elements that are TotallyOrdered.  For example:

        def sort(x):
                if __debug__:
                    for i in x:
                        assert i in TotallyOrdered      # or whatever
                # continue with the sort here.

If someone uses my sort function to sort a container of objects that are
not of built-in types, I don't mind imposing the requirement on the
user to affirm that those types do indeed meet the TotallyOrdered
requirement.  What I do not want to do, however, is require that the
person making the claim is also the author of the class about which
the claim is being made.

Incidentally, it just occurred to me that if we regard categories
as claims about types (or, if you like, predicate functions with type
arguments), then it makes sense to include (Cartesian) product types.

What I mean by this is that the TotallyOrdered category is really a
category of pairs of types.  Note that the comparison operators generally
work on arguments of different type, so to make a really appropriate
claim about total ordering, I really need a way to say not just that
a single type (such as int) is totally ordered, but that all combinations
of types from a particular set are totally ordered (or not -- recall that
on most implementations it is possible to find three numbers x, y, z
such that total ordering fails, as long as you mix int and float
with sufficiently evil intent).

Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark