I'm leary of trying to weave some interface taxonomy into the standard library and types without having a lot of experience in using this for real world applications. Even then, it's possible <wink> that there will be a lot of disagreement on the shape of the type hierarchy.
That's what I said when I predicted it would be hard to come up with an ontology. :-)
So one strategy would be to not classify the existing types and classes ahead of time, but to provide a way for an application to declare conformance to existing types in a way that makes sense for the application (or library). The downside of this is that it may lead to a raft of incompatible interface declarations, but I also think that eventually we'd see convergence as we gain more experience.
This is what Zope does. One problem is that it has its own notion of what makes a "sequence", a "mapping", etc. that don't always match the Pythonic convention.
My guess would be that of all the interfaces that get defined and used in the Python community, on a few that are commonly agreed on or become ubiquitous idioms will migrate into the core. I don't think we need to solve this "problem" for the core types right away. Let's start by providing mechanism and not policy.
Sure. But does that mean the mechanism needs to be necessarily separate from the inheritance mechanism? --Guido van Rossum (home page: http://www.python.org/~guido/)