[Types-sig] Interface PEP

[Marcin 'Qrczak' Kowalczyk]

Thu, 22 Mar 2001 16:54:51 +0100, Sverker Nilsson <sverker.is@home.se> pis=
ze:

> I could likewise invent something like 'abstract' type and say the
> point of it is to not say anything about implementation.

Ok, so you call 'type' what I call 'interface'.

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

A concept called 'type' already exists in Python and it specifies a
concrete representation. It's stronger than a class in this respect:
a class instance can have unspecified local attributes.

> > Since it determines what f assumes about x and which objects
> > are acceptable for x, it seems natural to call it an interface.
>=20
> I don't agree. It is too constraining to require that you only can
> specify an interface here.

It's not constraining, because interfaces are more general than types.

> > For example "sequence" and "file-like object" are already existing
> > Python interfaces, even if not strictly defined.
>=20
> Types that specify certain interfaces, I'd say.

They are not types. There are types in Python but none of them is
called "sequence". But there is an informal interface (or protocol)
called "sequence".

> It would stretch the meaning of interface too much to require it to be
> able to specify everything. You'd be better off just calling it a type,
> not imposing any implied restrictions that you nevertheless will work
> around.

You have it backwards. It would stretch the meaning of type too much
to require it to be able to specify everything. You'd be better off
just calling it an interface, not imposing any implied restrictions
that you nevertheless will work around :-)

> > For convenience we can allow type objects and class objects to be
> > used as interfaces directly, instead of having to explicitly obtain
> > the interface generated by a type or class.
>=20
> This seems wrong. Starting with a specific term 'interface' and then
> allow different terms, general or specific, to be used in its place -
> doesn't make sense to me.

It just implies that class objects and type objects conform to the
interface of interfaces, with obvious implementation of functionality
declared in this interface: namely which check that an object has
this very type or class.

> This is assuming type is really a general term. You seem to mean
> it always has to specify an 'implementation'. I don't know where
> you get that notion?

>From Python.

> The following quote doesn't say anything implementation of a type.
>=20
>     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.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK