[Types-sig] Interface PEP

[Sverker Nilsson]

To avoid some confusion maybe we should recognize that there is some
separate issues here. We are discussion essentially the y in the
following syntax.

def f(x:y)

The question is: what is the y.

1) 'interface'
2) 'type'
3)  something else

One could claim 'don't call it interface' without saying 'call it type'.

Marcin 'Qrczak' Kowalczyk wrote:
> 
> Thu, 22 Mar 2001 16:54:51 +0100, Sverker Nilsson <sverker.is@home.se> pisze:

> > I don't agree that a type needs to specify an implementation. It can,
> > but not necessarily. For me, type is a general term that can be used
> > to specify anything at all.
> 
> No, 'interface' is a more general term. It can require a specific type
> or allow more flexibility. It can specify an arbitrary requirement
> about objects.

As you know, I don't agree. We can't prove these things anyway - or
can you? If not, where do you get this notion from, that interface
could specify anything arbitrary? 

I know that 'interface' is a term used in programming languages, maybe
it was introduced as a program construct first with Java, but I really
don't know. It doesn't matter. I think they are wrong using it as a
general typing term, we don't need and should not follow bad examples,
without thinking deeper.

I'll just try to illustrate my view with an example from general
engineering.

If I buy a hard disk, I can choose interface SCSI or IDE. It would be
very confusing if when the sales person asked me what interface I
want, I answered something that was not the interface at all - like
the size of the disk.

But if they asked what type I wanted, I could conceivably answer
'interface SCSI' or '100 GBYTE' or 'IBM' or 'q9749-zop'whatever.

It would be wrong if they ONLY asked me for the interface. I need to
be able to specify more. In this case I most likely want to specify
the size as well, which is clearly (arguably??) not part of the
interface.

In other cases the interface may be all you want to know. It would be
strange if an adapter card was to be restricted to a specific size. It
should at most have a specific interface, SCSI or IDE.

Sometimes we may confuse the interface with the inner qualities, or
implementation. Some people perhaps care mostly about the interface,
i.e. the color, shape and other surface qualities, when choosing a
thing like a car. An attitude of only looking at the surface can lead
to bad car choises.  Sometimes it turns out ok. Your mileage may vary.

IMHO, a major problem with calling everything 'interface' (or
'protocol' for that matter) is that it could confuse people to believe
that it is always only the surface that matters, and that that is 
always the only thing that could and should be specified.

> 
> A concept called 'type' already exists in Python and it specifies a
> concrete representation.

I don't see anything in the Python reference manual saying that a type
must specify a concrete representation,

Some recent numeric proposals suggest that the same numeric type
should be able to have different representations. I don't think the
complaints about that are based on that it would change the Python
definition of type. Complaints are likely to be that it could break
backwards compatibility. One can think of other changes in the future
that choose different representations for the same type.

You may counter now that types are close to classes as you claimed
before, and I agree classes specify specific implementation. But I
think I showed in the previous mail how types (that is, what type()
returns) is likely to stay separate from classes - it would be no gain
making them the same and it would create (severe) backwards
compatibility problems.

So Python types seem to be free to be generalised.

> It's stronger than a class in this respect:
> a class instance can have unspecified local attributes.

So can a function, if function attributes added as proposed.

[snip]

> > The following quote doesn't say anything implementation of a type.
> >
> >     The notions of type and class are often confounded in
> >     object-oriented programming languages. In fact they play quite
> >     distinct roles, and can be usefully distinguished from each
> >     other. Types provide interface information that determines when
> >     certain operations are legal, while classes provide implementation
> >     information including the names and initial values of instance
> >     variables and the names and bodies of methods.
> 
> Ok, but this is a different thing called 'type'. Python already uses
> the term 'type' with a much more specific meaning.

As I indicated above, I don't agree with this.

    An object's type ... determines the operations that an object
    supports (e.g., ``does it have a length?'') and also defines the
    possible values for objects of that type

That's from my Python Reference Manual section 3.1.  It is just meant
to illustrate my point - there could be some other place that says that
a type is always bound to a specific implementation, but I haven't
seen any. Even if there was, it could be changed to allow more general
types, in a backward-compatible manner.

However, I might agree to agree that the term 'type' could have some
connotations to implementation. Or not, depending on your background.
Possibly we could use some other word, 'kind' for example.

I'd prefer 'type', but definitely not 'interface'.

Regards, and have a nice weekend!

Sverker