[Types-sig] Interfaces (was: definition of "type")

[Martijn Faassen]

Paul Prescod wrote:
> 
> Martijn Faassen wrote:
> >
> > Paul Prescod wrote:
> > [snip]
> > > I'm on the fence about this last requirement because I would like to
> > > think that all of the code out there with class statements is *already*
> > > defining a bunch of types. A minority of it depends on runtime
> > > information and we can easily detect those cases. So why not let the
> > > simple case of "defined class that doesn't depend on runtime
> > > information" be a shortcut for a type declaration?
> >
> > Are you sure that in fact a minority depends on runtime information?
> 
> Note that I'm saying that the vast majority of Python classes are
> statically declared, not that the vast majority of Python *code* is
> statically type checkable.

[just responded to your other response to me, but here you address my
concern in that response, so...I've hopelessly confused everyone now]

Okay. We should look into this issue, though. Ideally it should be as
easy as possible for the current Python programmer to adapt his code to
use types. I think interfaces are the answer here more than a common
base class.

Here I'll go off on a tangent that may help here:

Possibly this is a wild idea (or possibly it's old hat to everyone), but
what about a system to produces interfaces without having to declare
them? Take the intersection of two class interfaces and call this a new
interface; all methods with the same signature (and possibly members).

class Foo conforms FooInter:
   def getS(self)->String:
       ...

   def otherstuff(self):
       ...

class Bar conforms FooInter:
    def getS(self)->String:
        ...

    def otherstuff(self, a, b):
        ...

class Baz:
    pass

Foo ! fooInter # works
Bar ! fooInter # works
Baz ! fooInter # TypeError

Alternatively you could move the interface declaration code outside the
classes, into something like this:

decl interface FooInter: intersection(Foo, Bar)

This way programmers don't need to explicitly declare interfaces and
still have them. I don't know if this is a good idea though; there's a
lot to say for explicitness. These intersections may be too big,
containing overlaps you aren't interested in. Though of course it's easy
to explicitize it and prevent this, too, if you want:

class ExplicitInterface conforms FooInter:
    def getS(self)->String:
        pass


Though in this case you could make the interface too small if not all
conforming classes actually implement a method. So you'd need something
like:

class ExplicitInterface defines FooInter:
    ...

to be really sure you get compiler errors if not all classes conform.

Sorry to fill the SIG with discussions on interfaces. They just seem
unavoidable if you want to preserve lots of interesting Python features. 

Python right now is after all often used in a way that decouples
interface from implementation without explicitizing the interfaces (for
instance cStringIO, File, etc). This idea would at least make them more
explicit with minimum programmer-hassle, while still providing for full
explicity if desired. In this way it is similar to current Python
practice; you can make interfaces fully explicit by using a common base
class.

Regards,

Martijn