PEP 245: Python interfaces

[Michel Pelletier]

On 24 Mar 2001, Martin von Loewis wrote:

> The following message is a courtesy copy of an article
> that has been posted to comp.lang.python as well.
>
> Michel Pelletier <michel at digicool.com> writes:
>
> > I'm the author of PEP 245, a framework and syntax for interface objects in
> > Python.
> >
> > http://python.sourceforge.net/peps/pep-0245.html
> >
> > It has just recently been made a PEP, and I'd like to solicite some more
> > input from the community (you).
>
> Even though this is quite a long document, it is incomplete.

Yes, *sigh*.  I know I need more formalism, but should this be at the
expense of the section on goals?  I'm not sure.  I was raised in an XP
environment, the goals are the most important part to me.  This is
something I've been debating myself over.  I obviously want the PEP to be
accessable and not boring, but I also want it to be comprehensive.

> This is
> probably not surprising since it is the first draft, but to really
> evaluate, I think a number of details should be added. In order of my
> preference:
>
> - proposal for a concrete syntax. The PEP should provide a detailed
>   specification of the grammar changes, preferably in (A)EBNF or the
>   Grammar/Grammar format. Currently, only a "Syntax Overview" is
>   given; that doesn't answer all possible questions. In particular,
>   the role of the "implements" reserved(?) word is never specified.

Good idea, I'll try to emulate Guido's informal grammar description from
the Language Reference.

> - detailed description of the contents of the module Interface.  For
>   example, Interface.Exception.BrokenImplementation is used but not
>   defined. For the moment, I assume that the proposal has the same
>   definitions as the reference implementation.

Yes.  I'll try to be more complete for the next draft.

> - a reference implementation that works as a patch to Python. This is
>   probably not needed at the moment, but certainly prerequisite for
>   people to completely evaluate the PEP.

Yes, at the moment, I feel I'm somewhere near that point in the PEP
process as described by PEP 1:

"The PEP should be reviewed and accepted before a reference implementation
is begun, unless a reference implementation will aid people in studying
the PEP."

> I like many aspects of the draft, but a few points should be
> corrected, IMO:
>
> - naming of the Interface package. Few standard modules are in
>   uppercase, and I think this shouldn't be uppercase, either. Instead,
>   I'd prefer a module "interfaces", in analogy to the types module.

Good idea.  It's current spelling is an artifact of the reference
implementation.

> - packaging. I think the hierarchy is too deep, everything should be
>   contained in the interfaces module (there is not an awful lot of
>   stuff in it, is there?).

How do you mean?  I don't think the PEP proposes any depth beyond the
Interface module.

> - exceptions. I think the standard exception hierarchy should be used
>   better, e.g. inheriting from NotImplemented (or directly using that
>   exception) where appropriate. Also, BrokenImplementation seems a bad
>   choice of wording; Smalltalk uses subclassResponsibility to indicate
>   that an abstract method is not implemented.

I'll look into that, certainly reducing any amount of new exceptions is a
good idea.

> - nesting of interface assertions. Why is it necessary to support
>
>    implements FooInterface, (BarInterface, (BobInterface, MyClass.__implements__))
>
>   Wouldn't it be sufficient (and more consistent with classes) to write
>
>   implements (FooInterface, BarInterface, BobInterface)+MyClass.__implements__

I do not know the exact motivation behind Jim choosing a DAG to describe
an interface assertion.  I'll find out.

> - Access to fields. I think it is confusing that you won't write
>   Iface.feature, e.g. in
>
>   interface Iface:
>     def feature(self):
>       "does something"
>
>   Instead of writing Iface.feature, it appears that you write
>   Iface.getDescriptionFor("feature"). It would be better if attribute
>   access could be used.

Ah yes, this is an interesting point of debate.  The idea here is that the
interface of an interface is *not* the interface that it describes.  I was
not around when the types-sig (and Jim) came up with this; I cannot give
you the exact motivation, but it feels right to me.  If you'd like, I can
add a section to 'Dissenting Opinions' section on this point.

Thanks Martin!

-Michel