[I'm chopping the recip list to just types-sig -BAW]

> >>>> "GM" == Gordon McMillan <gmcm@[...].com> writes:

    GM>  In fact (as Barry was supposed to point out at the conference
    GM>  for me, harrumph, harrumph), the set of all interfaces /
    GM>  protocols is the set of all subsets of the set of all
    GM>  signatures - without taking behavior into account. That is,
    GM>  the set of all interfaces has a cardinality that I don't
    GM>  particularly want to contemplate.

Yes, my fault for not bringing that up, but you've done a fine job in
my lapse!

> >>>> "TP" == Tim Peters <tim_one@[...].com> writes:

    TP>  OTOH, unlike e.g. JimF I have nothing against stuffing some
    TP>  default implementation into interfaces.  To the contrary, if I
    TP>  *wanted* to say that all List implementers implement Stack
    TP>  too, I think

In fact, I want a different kind of error to get thrown when a class
says it implements a particular interface, but in fact neglects to.
If I have a class List that claims to implement interface Stack, but
in fact does not provide an implementation of pop() or push(), I don't
want an AttributeError when I call one of those methods on an instance
of List.  I want something like a NotImplementedError.  I think this
important enough to guarantee in language spec.

Tim also wants to allow implementation in an interface definition,
because some methods can be defined solely in terms of other methods
in the interface.  That seems fine to me.

    GM>  True. One would not even try to enumerate all possible
    GM>  signatures.  The point is, though, that there's a conflict
    GM>  between precision and usability. If interfaces are too
    GM>  precise, they will multiply with abandon and become
    GM>  unmanageable. To prevent that, people will choose the
    GM>  "closest" interface. So the "requirer" will ask for more than
    GM>  is actually needed, and the "requiree" will have the choice of
    GM>  adding unneeded methods, wrapping unnecessarily, or lying.

This is a good point, and I'm reminded of a discussion that Guido and
I had when we were talking about the class-exceptions heirarchy.  We'd 
drawn up several possibilities, some quite complicated, but we had too 
much trouble assigning the proper semantics to the classes that we
decided to flatten the heirarchy as much as possible, and leave it to
applications to decide on deeper heirarchies.

I think the same approach will have to be taken with the core
w.r.t. interfaces.  Keep the set of interfaces defined by the core as
shallow and small as possible, but provide enough rich mechanisms so
that applications can build higher level stuff easily.

-Barry