[Types-sig] Interface PEP

[Michel Pelletier]

On Wed, 14 Mar 2001, Sverker Nilsson wrote:

> Ok, I read it again closer now. Well, what I can agree with is that
> the interfaces are _descriptions_: more for the human reader, than for
> (dynamic or static) type-checking.

Their role in type checking is not determined, and the concept is
(possibly) out of scope of the PEP.  They can, however, be used for
run-time checking in many flexible ways, including, I belive, type
checking.

> I could consider the type of an object to be something different
> than the interface, but then _also_ different from the class,
> contrary to what you imply below.

Yeah I was just mixed up.  I wasn't thinking along the lines of the very
specific definition of type and looking toward the future where types and
classes become one.  Maybe I missunderstand the core of the type/class
dichotomy problem.

> Maybe a useful combination of the type and interface objects would be
> that the type _contained_ an (optional) interface description.

Another useful combination is the exact opposite, the interface describes
the expected types of the implementation.

> > Many different objects of different types many also implement the *same*
> > interface.  For example, lots of different types of objects can be a
> > sequence or a mapping.

> >  "sequence" and "mapping" are not types like lists
> > and dictionaries, they are just protocol descriptions, or interfaces.
>
> I'd say SequenceType or MappingType should be types just as well as
> ListType.  Why make them different kinds of things?

Well, in my world, sequence and mapping are interfaces, not types.  This
is not only a slippery slope, but a hairy issue indeed.

> I'd say ListType is a _subtype_ of SequenceType. With this I mean:

I'd say that lists implement the sequence interface.

> Using interfaces as types, I guess one could do it with isInstance on
> the interface object. (Or maybe one wants something more flexible.)

You would ask the object if it impliments the interface you're looking
for.

> > In Zope, we may have a RelationalUserFolder, and a FileUserFolder,  both
> > completely different implementations and different types, but they both
> > implement the UserFolderInterface.
> >
> > In many ways, interfaces achieve a lot of what a stronger typing system in
> > python strives to achieve.  This doesn't mean they can't co-exist, and I
> > posit any idea type system in python would be intimately involved with the
>
> What does posit mean? (Not in my dict.) Like 'appreciate'? I suppose
> so in the following!

Oh it may be slang, it means "to have a position" or "assert".

> > interfaces (often refered to as "protocols") of objects.
>
> Well am I right to understand that interfaces are not meant for
> typechecking, but mostly for a kind of description?

They could concievable do type checking.

> Then I think they would still be useful, maybe as a field in the
> actual type objects.

Or, as I said, interfaces could, vice versa, assert their elements must be
of certain types.

-Michel