[Types-sig] Interfaces API

[Michel Pelletier]

On Wed, 14 Mar 2001, Paul Prescod wrote:

> We'll need to agree on an API for interfaces. My API is very simple:
>
> interface Interface:
>     """The shared behavior of interface objects"""
>     def __check__(self, obj)

Well, i'm not sure how yours works.  Is there a description somewhere?
I'm wondering if you're interface objects describe their elements are
attributes of that object.  For example, in your model:

interface Foo:
  def bar():
    pass

Does this make a 'Foo.bar'?  We don't go that way, because we don't think
there's any usefulness in it.  The interface of an interface is *not* the
interface that it describes, in our model.

> Michel's is a little more "feature rich":

<snip>

> I'm surprised that you don't have the equivalent of my __check__.

I don't know what it does.

> Given
> an object don't we want a way to ensure that it really does have the
> right names, methods with the right parameters and so forth?

Oh, I see.  yes we have a method for this, but it is not part of the
InterfaceInterface because we don't think it's that important.

> In my mind,
> __check__ is the major feature required for runtime checks. The other
> stuff is of lesser interest ot me.

But checking for the right number of names, methods, parameters, and even
their types, is only a minor Java-esque win.  There's certainly no
guarantee that the implementation will work in any way at all the way its
interface describes, and no way to test that quickly.  For that, unit
tests are ideal.  Actually, we've been thinking about that alot and we've
think that interfaces + unit tests are pretty damn cool.

Anyway, about your second point, we have the complete opposite philosophy:
run time checking is of lesser interest to us.  Flexible, rich
introspection for tools and programmers to address the stated goals in the
PEP is our main focus.  Not run time checking.

> Also, I wonder if an API could get into the core language with
> CamelCaseMethodNames. Guido Isn't A CamelCaseGuyAfterAll. I really
> prefer camel case myself but what's the point in fighting the BDFL on
> religious issues? (I'll point out, however that camel case names would
> have a consistent syntax for hasAttr and hasKey, which Python does NOT!)

I'm not emotionally commited either way. ;) Any case Guido recommends is
fine with me.

-Michel