[Types-sig] Interface PEP

Samuele Pedroni pedroni@inf.ethz.ch
Thu, 15 Mar 2001 04:53:32 +0100


Hi.

It seems there is a bit of confusion.
I think the following issues are quite orthogonal:
1) the purely runtime mechanism for enforcing args and return value _domain_
checking  under devel.
2) the kind of "type" systems that can be used or experimented with 1)
3) intefaces as defined by the PEP

[mostly a summary, at least I hope]
1) with syntactic sugar (that for the moment we do not have):
    def f(a: D1,b: D2) -> D3
       ...
       return r

   will test at runtime whether a,b on entry and r on return pass:
      D1.__implementedBy__(a)
      D2.__implementedBy__(b)
      and D3.__implementedBy__(c)
  so D1,D2,D3 are "algorithmic" hints/definitions of the domain, codomain of f

2) it would be nice to have a set of predefined domain checks and domain
constructors  ideally they would build up a type system, but 1) in principle
enable any kind of decision and can even be used mixing up different
paradigms.
A possible goal and test-case is to annotate in such way the std lib.
Now the algorithm in the standard lib work has long as the inpunt support
the needed operations (protocols), at the moment python does not require that
inputs inherit from abstract classes or explicitly declare  to implement some
interfaces: e.g. simply as long as an object supports __getitem__ it is a valid
input to:
   def first(a):
     return a[0].
So the domain for a is "supporting []" (being a SequenceType or implementig
__getitem__). To be appropriate for annotating the std lib. domains must
algorithmically (and 1) allows for  that ;)) check if a protocol is
implemented.
To enforce that inputs explicitly declare to implement an interface *does  not*
correspond to the actual practice and potentially would require a lot of
changes in the existing code around that uses the interface.
OTOH the latter kind of check wheter an input explicitly implements an
interface can be implemented and fits with 1, and like Tim Hochberg has
proposed having wrapper or abstract classes to enforce a protocol is also ok
and nice for future code.

3) The idea of interface as proposed enforces and documents design and somehow
enforces what we have called a protocol (implementing a set of ops (methods))
and is orthogonal with 1):
*  one can check wheter an input explicitly declare to implement an
     interface (interfaces could have their __implementedBy__)
*  ideally there could be a constructor that produce a protocol domain
    checker out of an interface:
         JustProtocol(FooInterface).__implementedBy__(baz):
    checks whether baz declares to implement FooInterface (this for speed),
    or checks wheter baz defines the methods required by FooInterface
*  if we endup having signatures for functions (def f(a: D1) -> D2) interfaces
    could be defined with them and check for them too.

Note: protocols as intended do not form an explicit hierarchy, but there is an
inclusion
relation.

regards Samuele Pedroni