[Types-sig] Interface PEP

[Marcin 'Qrczak' Kowalczyk]

Mon, 26 Mar 2001 18:34:47 +0200, Sverker Nilsson <sverker.is@home.se> pis=
ze:

> > > def f(x:y)

> Seems you lost me here... It will actually return a type, 'the' type,
> for all I can tell. In the body of the function f defined above,
> type(x) will be a type that is a subtype of y.

There is no subtyping. I see no even a candidate for that relation.
Types in the Python's sense are not ordered, types in your sense
(i.e. interfaces in my sense) are not ordered either. What do you
call subtyping in the context of Python?

Things to which 'y' belongs are disjoint with things 'type(x)'
returns (unless you allow the shortcut of using a class or type
as interface directly, without obtaining interface generated from
a type explicitly, but it's a special case and works only in one
direction: types/classes can be used as interfaces, arbitrary
interfaces can't be used as types/classes).

There is a relation of conformance, but it's between objects and
interfaces. It often depends only on the type or class of the object,
so it's usually a relation between types/classes and interfaces.

If I replaced "interface" with "type" in the above two paragraphs,
I would get complete nonsense. So you cannot artificially put types
and interfaces in one bag. All the time you would have to distinguish
when you mean a type in the sense of "template of object definition"
or "description of how an object can be used". They are very different
concepts. When I am using an object, I'm not interested in its type,
but in supported operations and their meaning.

> What type() returns is in general an over-estimate of the set of
> allowed values. It is 'the' type that the object decides it wants
> to tell the world it's got. As long as it is not telling us an
> under-estimate, it is ok for the object to tell us any type that
> it is indeed compatible with.

There is no order among types, so I don't know what do you mean by
over-estimate or under-estimate. A type unambiguously defines a
set of values. Sets of values for different types are completely
disjoint. So there is only one possible thing type() can return:
every object has exactly one type according to Python's definition.

OTOH an object conforms to many interfaces. You can check if a given
object conforms to an intreface, and you can obtain operations defined
by the interface as applying to a given conforming object (it's not
yet clear how exactly it would look like).

Sorry, I don't see what do you gain by calling two completely different
concepts using the same name.

The fact that other objects use the term "type" as "interface"
is irrelevant, because Python already uses the term "type" in a
different meaning.

> Thus it seems conceivable that of two otherwise similar objects,
> for example of some list implementation, one could tell us it was
> SomeListType and the other say it was some more general SequenceType.

No, it does not make sense to let type(x) *ever* return SequenceType,
assuming that SequenceType describes the informally existing Python's
interface of lists, tuples, strings, xranges etc.!

It's because objects conform to independent interfaces independently.
When something is a sequence and also is storable-in-Foo-database,
neither of these interfaces is fundamentally more important than
the other. Neither implies the other, so they can't be related by
subtyping.

type(x) cannot generally return interfaces. "Sequence" is only
an interface - it describes how to use an object, not how it was
defined, and is orthogonal to most other interfaces. If type(x)
sometimes return types, and sometimes interfaces, it's inconsistent.

How do you decide which of interfaces supported by an object to return?

> To have things make sense in this case, SomeListType should have
> been declared to be a subtype of SequenceType.

What are your definitions of "type" and "subtype"? How types are
created and how the subtyping relation is established?

If the subtyping relation is established by explicit assertions,
does it make sense to assert that something is a subtype of IntType?
Since IntType defines the representation, IMHO it doesn't make
sense, which implies that at least two families of objects have been
artificially put into one bag labelled "types".

> > Of course there would be gains: you could inherit from files, and
>=20
> You could still do that, at least from file *classes*: you inherit
> from something like metaclass(FileType). I thought I told you this
> quite clearly previously!

Why to be forced to convert files to classes, instead of having them
unified in the first place? What do you gain by their separation?

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