[Python-Dev] type categories

[Michael McLay]

On Monday 26 August 2002 10:45 am, Guido van Rossum wrote:

> > 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?

Several posts have expressed a need to support multiple ontologies for a given 
set of classes. This doesn't preclude using the ontology that is defined by 
the class hierarchy as one method for defining an ontology. That could be the 
default ontology. What is missing is the ability to also place a class in to 
an alternate ontology that may be specific to an application.  The problem 
could be solved if applications had the ability to add and delete references 
to the type interface definition that apply to a class.

Aclass.declaretype(AnInterface)
Aclass.deletetype(AnInterface)

Perhaps the interface definitions should also be able to add themselves to 
class definitions. That way common interface patterns that apply to standard 
libraries could be defined in the standard library. This would eliminate the 
repeated addition of interfaces to classes in each application.

Interface I:
  pass

I.appliesto(Aclass)

Removing an interface from a class might not be possible, or it may require a 
second class implementation to be created at compile time, because usage of 
that interface may be required in some other module. I suspect having two 
implementations of the same class might be somewhat confusing to the user. 
Perhaps removal of a required interface would trigger an exception.