Why PEP 245??

[Corran Webster]

In article <mailman.991240065.16936.python-list at python.org>,
<nanotech at europa.com> wrote:

> As it seems to be now, an Interface is similar to a class which has no
> implementation, but *requires* doc-strings. But what keeps the
> doc-strings meaningful?

Nothing, other than good coding practise.  But that's true of all
doc-strings.

> Let me go out on a limb and post code (untested because I do not have
> access to a build with interface implemented):
> 
> 
> class square:
>     def __init__(self):
>         pass
>     def show(self):
>         "Doc-string specific to square.show"
>         print """
> *****
> *   *
> *   *
> *****
> """
> 
> class circle:
>     def __init__(self):
>         pass
>     def show(self):
>         "Doc-string specific to circle.show"
>         print """
>  ***
> *   *
> *   *
>  ***
> """
> 
> class triangle:
>     def __init__(self):
>         pass
> 
> 
> Now we could add an interface:
> 
> 
> interface ShowInterface:
>     "Classes can _show_ themselves"
> 
>     def show():
>         "Display ASCII representation of the object"
> 
> 
> and I modify my class definition:
> 
> 
> class square implements ShowInterface:
> 
>  <nothing else changes>
> 
> class circle implements ShowInterface:
> 
>  <nothing else changes>
> 
> class triangle implements ShowInterface:
> 
>  <nothing else changes>
> 
> 
> But now what? What makes sure the doc-strings stay current or make
> sense? Does a "ContractUnfulfilledError" occur when I create an
> instance of 'triangle' because 'show' was never defined/implemented?
> In short, what can I do now that I could not?

According to the proposal, these definitions would not generate any
sort of error - and that's reasonable because even though triangle
doesn't satisfy the interface on definition, Python is sufficiently
dynamic that it could be changed on-the-fly to satisfy it; or maybe
triangle class is meant to be an abstract class with subclasses like
IsocelesTriangle and EquliateralTriangle which always satisfy the
interface (which would probably be bad design, but shouldn't be
outlawed, I guess).

What the PEP allows is run-time testing for compliance to an interface. 
For example:

def showlist(mylist):
    for object in mylist:
        if implements(object, ShowInterface):
            object.show()
        else:
            print str(object)

This would fail if you fed it a list containing a triangle instance,
but that's a fairly easy error to detect.

The PEP would also assist debugging through assertions.  For example:

def describe(object):
    assert implements(object, ShowInterface)
    print "The object you have selected looks like:"
    object.show()

You can do these sort of tests in Python already, for example:

def implementsShowInstance(object):
    return (hasattr(object, "show") and callable(object.show))

but this sort of thing is tedious at best if you have lots of complex
interfaces, and still doesn't full capture all the information that the
interface gives, such as the number of arguments to show and any
default arguments (it's possible to discover these, but it is a lot of
work).

The problem you describe with the triangle class can be ameliorated as
described in the PEP by using the deferred method of the interface:

Showable = ShowInterface.deferred()

...

class triangle(Showable):
    ... # as above, doesn't have a show method

triangle.show()   # gives an explicit error message

But perhaps the most important reason for having something like the
interface proposal is that Python already uses the concept of
interfaces, but without any formal mechanism for supporting them in the
language.  There is talk about "file-like" objects and "callable"
objects and "sequences" and "mappings" in the documentation, and there
is a rough consensus amongst developers about what these interfaces
are, but no explicit definitions of exactly what methods an object
needs to be considered to satisfy the interface.

Hope this helps,
Corran