PEP 245: Python interfaces

[Clark C. Evans]

On Fri, 23 Mar 2001, Michel Pelletier wrote:
> >
> >          class X:
> >             def func(self,z): pure
> >
> >       Then, if any method in a class was marked
> >       "pure", the class could not be instantiated.
>
> 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. 

Yes, but a class full of "pure" methods is an interface, no?
Further, you can be more granular with this approach.  For instance,
you may have an interface with four functions.  The implementation
of three functions may be completely optional or trivial.  With
the class approach, you could label the one critical method as
"pure" and then provide a reasonable, default implementation 
for the other methods.

> Classes could in some way, be extened to have an inline "interface"
> but that is mixing your interface with your implementation.

I'm not convinced that they are entirely seperate ideas.

> How can you reuse that? 

Just like you use classes today... look at the PyXML stuff,
specifically the Sax interfaces.  Providing a default, or
trivial implemenation for optional methods is a common 
technique in C++ and very valueable.  

In Java you are forced to have two constructs, an interface,
and then a "base handler".  Having the interfae and the
base implementation in two places just makes more places
where errors can pop-up.

> How can you have mulitple implementations?

Pretty easily, see the PyXML stuff, specifically
the SAX 'interfaces.

> >    f) If a new type is added, why not go further?
> 
> Because I don't want to risk sliding into the absurd. ;)
>

Yes, but your new interface type isn't providing much
that can't already be done with classes and regular 
inheritance.
 
> >       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.

Something like this would make your proposal as offering
something significant which classes don't already offer.

> >    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?

For starters my syntax highlighter doesn't work with them.
Also, nested blocks and such can't be used.
If you have a new syntax... why do they have to be strings?
 
> >        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?

I don't think the above prevents this, I was just looking
at a more "pythonic" syntax.  Checks are *code*, IMHO, 
they don't belong in strings.  The syntax above is just
an attempt to make it more code like.  

Best,

;) Clark