PEP 245: Python interfaces

[Martin von Loewis]

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

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

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

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.

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

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

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

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

Regards,
Martin