Python Interfaces

This page is intended to provide a location for up-to-date information on a "Python Interfaces" effort.

Developer's Day, 1998

At the Seventh International Python Conference, there was a session on Developer's Day to discuss a mechanism for building "interfaces" in Python. An interface is a specification for object behavior that is separate from implementation. A description of the problem being solves was provided in the Proposal, for the Developer's day session. Some additional ideas were provided in a Pre-Proposal, published prior to the meeting. The summary, of the developer's data session was published after the meeting. This summary included a Scarecrow Proposal for an implementation of interfaces that doesn't require Python language changes.

It was decided that a SIG should be formed to:

• Settle Jargon issues
• Flesh out and implement the Scarecrow proposal
• Perform work/prototyping for a follow-on more comprehensive proposal that:
  • Reflects experience with the Scarecrow
  • May involve language changes (for Python 2.0)
  • May introduce richer interface models such as "design by contract" (pre- and post-conditions and invariants)
• Work with the "types sig" so that static typing features take advantage of interfaces.

The interface discussion in the types-sig

A types SIG, was established to discuss three topics, including Python interfaces. A lively discussion took place during November and December of 1998 regarding the points raised in the pre-proposal and scarecrow proposal.

Objections to the proposal seemed to fall into three categories:

• Some people were opposed to adding static typing to Python and saw "interfaces" as a step in that direction.

  It is true that if static types are ever added to Python for the purpose of type safety, then they should certainly take advantage of interfaces, however, interfaces are useful without static typing.

• Some people felt (and perhaps still do feel) that a separate interface mechanism is unnecessary and that abstract base classes (ABCs) would provide the same benefit. The counter arguments to the ABC suggestion included:
  • ABCs do not provide enough separation between implementation and interface (specification),
  • The ABC approach requires that sub-classes must implement all of the interfaces of their base classes. Some people consider this to be overly restrictive,
  • In the ABC approach, it is hard to tell which base classes contribute contractual requirements (interfaces) and which base classes simply contribute implementation.

Another benefit cited for the ABC approach is that an ABC can include implementation defined in terms of an abstract interface that be inherited by sub-classes. Note, however, that an interface-based approach does not preclude the use of ABCs. An ABC can be developed in terms of an abstract interface and sub-classed by classes that provide implementation for the interface.

• An alternative proposal was made for an interface model based on functional programming and formal methods. In this proposal, objects and classes don't implement interfaces, functions and methods do. This approach may have merit. The scarecrow proposal sought to provide an OO-based interface model.

Much discussion focussed on the rational for separating interface and implementation.

There was also some discussion on jargon issues. For example, the notion of interface used here is more closely related to the notion of protocol and specification than it is to C or Objective-C "interfaces". In the end, some benevolent dictators got together and dictated that the term interface would refer to a Python object that describes a specification and that the term implements would be used to refer to a promise made by a class to honor and interface.

The 0.1 version of the implementation was released in early December of 1998.

If I've left anything out or gotten anything wrong in summarizing the SIG discussions, please let me know.

Current status

The scarecrow proposal is being released, to the Python community at large. Efforts will be made to incorporate interfaces into Zope.

Comments on this document and on the effort in general are welcomed.