[Python-Dev] type categories

[Barry A. Warsaw]

>>>>> "GvR" == Guido van Rossum <guido@python.org> writes:

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

    GvR> That's what I said when I predicted it would be hard to come
    GvR> up with an ontology. :-)

Actually, it'll be easy, that's why we'll do it a hundred times. :)

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

    GvR> This is what Zope does.  One problem is that it has its own
    GvR> notion of what makes a "sequence", a "mapping", etc. that
    GvR> don't always match the Pythonic convention.

Yep, that's a problem.  One approach might be to provide some blessed
or common interfaces in a module, but don't weave them into the
types.  OTOH, I suspect that big apps and frameworks like Zope may
want their own notion anyway, and hopefully it'll be fairly easy for
components that want to play with Zope to add the proper interface
conformance assertions.

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

    GvR> Sure.  But does that mean the mechanism needs to be
    GvR> necessarily separate from the inheritance mechanism?

It definitely means that there has to be a way to separate them that
is largely transparent to all the code that checks, uses, asserts,
etc. interfaces.  IOW, if we allow all of inheritance, __implements__,
and a registry to assert conformance to an interface, the built-in
conformsto() -- or whatever we call it -- has to know about all these
accepted variants and should return True for any match.

-Barry