[Types-sig] Interface PEP

[Sverker Nilsson]

Michel Pelletier wrote:
> 
> On Wed, 14 Mar 2001, Sverker Nilsson wrote:
> 
> > I was wondering why, or if, the new concept of "interface" should be
> > introduced. There is already the concept of "type" in Python. I
> > thought that concept could/would/should be extended to cover more
> > general interfaces.
> >
> > One would say then, I suppose, instead of
> >
> > interface x...
> >
> > something like
> >
> > typedef x...
> >
> > and the rest of the def would be essentially the same, I think.
> > Instead of the __implements__ special attribute, one would use
> > an attribute name more alluding to the type concept, I might want
> > to call it __type__.
> >
> > The type() builtin would return, as usual, InstanceType if the
> > __type__ special attribute was not defined. Otherwise it would return
> > what __type__ returned. - which would be a user defined type (aka
> > interface) or even a builtin type, if the class wants to claim it
> > emulates a built-in type.
> >
> > (Claiming is one thing of course, really doing it is another -
> > there can never be any guarantee, I suppose.)
> >
> > So.. what would be the reason to have interface another concept than
> > type?
> >
> > Or should they be the same concept?
> 
> They are different concepts.  Read the section in the PEP on "Classes and

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.

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.

Maybe a useful combination of the type and interface objects would be
that the type _contained_ an (optional) interface description. This
would not need to be used by the typechecker, which would compare the
types directly.

> Interfaces".  One class, or "type" of object, can implement multiple

So you identify the object's class with its type... why?

> interfaces, and a "type" consisting of an many mixed in classes can be
> used to implement just one interface.

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

Well I'd say "lots of different _classes_ of objects.."
Not types of - that would again prematurely fix what we mean
with the type of an object.

>  "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?

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

If we specify a function f that takes a parameter a of type x: 

def f(a:x):...

and call it:

f(y)

it is required that the type of y is a subtype of x. 

So if x was 'SequenceType', it would be possible to call it if 
type(y) == ListType, TupleType, SequenceType, or any other type
that was a subtype of SequenceType.

This could be checked (automatically) with for example:

	assert subtype(type(y), x)

or maybe

	assert x.is_supertype_of(type(y))

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

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

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

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

Here is my tongue-in-cheek micro-suggestion then :-)

Objects could have a __type__ field.
The builtin function type() returns the __type__ field if defined.
Type objects can be user-defined or builtin.
Type objects should implement at least a subtype or supertype method.
They can also have an interface field for the interface description.

Sverker