PEP 245: Python interfaces

[Michel Pelletier]

On Fri, 23 Mar 2001, Clark C. Evans wrote:

> > http://python.sourceforge.net/peps/pep-0245.html
>
> This is very good work  Michel.

Thanks.

> Here are my comments
> which I've been mulling over for the last few days.
>
>   a)  First, I'm not sure a new type is needed, perhaps
>       classes work just fine (see the PyXML library
>       for current interface declaration practices...)
>
>       In general, your PEP didn't convince me why
>       the class construct couldn't be extended
>       in a reasonable way to satisify the goals
>       you enumerated without introducing a new type.

The reason behind this is that classes are shared implementation, they are
not an interface.  Any interface of a class is an implied, assumed thing.
Interface assertions make that more concrete.  Classes could in some way,
be extened to have an inline "interface" but that is mixing your interface
with your implementation.  How can you reuse that?  How can you have
mulitple implementations?

>   Assuming that the "class" type can be augmented:
>
>   b)  If the class syntax was extended, perhaps it
>       may be useful to add a new statement like
>       pass, but could be used to mark "pure"
>       methods (like = 0 in C++), perhaps:
>
>          class X:
>             def func(self,z): pure
>
>       Then, if any method in a class was marked
>       "pure", the class could not be instantiated.

Same argument as above.

>   c)  If the class syntax was extended, perhaps
>       there might be a way to signify "inherit"
>       from "implements", perhaps:
>
>          class X (Y,#Z):
>
>       The above class X "inherits" from the
>       class Y, and "implements" the public
>       attributes found in class Z, but
>       without sharing the implementation.

Once again, this is mixing interface with implementation.  Z should not
be implementation.

>    d) What is also missing from Python is
>       an "auto-delegation".  An analysis
>       of how this fits in or doesn't fit
>       in would be helpful.

What is that?  I've neve heard of auto-delegation.

>    Assuming that a new "interface" type were
>    to be added.
>
>    e) I personally feel that the syntax should
>       be much different from the syntax of a
>       class to reduce confusion.  Note that
>       maps and lists have different syntaxes.
>       The different syntaxes give better
>       context for programmers...

Ok.

>    f) If a new type is added, why not go further?

Because I don't want to risk sliding into the absurd. ;)

>       Although I don't like the idea of argument
>       types in classes... they could very well
>       make sence for interfaces.  This could help
>       to differentiate the syntax, perhaps:
>
>         interface Y:
>            decl func( number as types.IntType,
>                       string as types.StringType,
>                       any    as any,
>                       cls    as IAnotherInterface ):
>                "This function does such and such"

These goals are reasonable.  I don't like the syntax myself.

>    g)  I like the pre/post condition stuff, however,
>        this shoudl be put in a seperate PEP as it
>        is seperable and could be added later, no?

Yes, that's probably a good idea, I'll look at it.

>    h)  I don't like the string for pre/post conditions.

They're just python expressions like that used with the 'assert' keyword.
What's not to like about them?

>        They should have special syntax, perhaps as
>        these could be implemented as "local methods?"
>
>          interface Y:
>              decl func(...)
>                  def pre(self):
>                     if ... then raise PreConditionFailure
>                  def post(self): pass
>                  def test(self): pass

What if you interface wants to have pre post and test methods that have
nothing to do with type enforcement?

> Wheu!  I hope this helps!

Thanks!

-Michel