[Python-Dev] type categories

[Alex Martelli]

On Saturday 24 August 2002 08:44 am, Guido van Rossum wrote:
	...
> For example, if we ever are going to add argument type declarations to
> Python, it will probably look like this:
>
>     def foo(a: classA, b: classB):
>         ...body...
>
> It would be convenient if this could be *defined* as
>
>     assert isinstance(a, classA) and isinstance(b, classB)

I was hoping this could be defined as:

    a = adapt(a, classA)
    b = adapt(b, classB)

but I fully agree that, if we have an elegant way to say "I'm inheriting JUST
for implementation, don't let that be generally known" (C++'s private
inheritance is not a perfect mechanism, because in C++ 'private' affects
_accessibility_, not _visibility_, sigh), it can indeed be handier and more
productive to have interfaces and classes merge into each other rather
than be completely separate.  Substantial experience with C++ (merged)
and Java (separate) suggests that to me.  From the point of view of
the hypothetical 'adapt', that suggests the 'protocol' argument should
be allowed to be a type (class), rather than an 'interface' that is a
different entity than a type, and also the useful implication:

    isinstance(i, T) ==> adapt(i, T) is i

> so that programs that have a simple class hierarchy can use their
> classes directly as argument types, without having to go through the
> trouble of declaring a parallel set of interfaces.

The "parallel set of interfaces" (which I had to do in Java) *was*
indeed somewhat of a bother.  Any time you need to develop and
maintain two separate but strongly parallel trees (here, one of
interfaces, and a separate parallel one of typical/suggested partial
or total implementations to be used e.g. in inner classes that
supply those interfaces), you're in for a spot of trouble.  I even did
some of that with a hand-kludged "code generator" which read a
single description file and generated both the interface AND the class
from it (but then of course I ended up editing the generated code
and back in trouble again when maintenance was needed -- seems
to happen regularly to me with code generators).  Surely making the target 
language directly able to digest a unified description would be nicer.


> I also think that it should be possible to come up with a set of
> standard "abstract" classes representing concepts like number,
> sequence, etc., in which the standard built-in types are nicely
> embedded.

If you manage to pull that off, it will be a WONDERFUL trick indeed.


Alex