Python Interface Syntax

PEP:	245
Title:	Python Interface Syntax
Version:	e2b5d1a8a663
Last-Modified:	2009-01-18 09:50:42 +0000 (Sun, 18 Jan 2009)
Author:	Michel Pelletier <michel at users.sourceforge.net>
Discussions-To:	http://www.zope.org/Wikis/Interfaces
Status:	Rejected
Type:	Standards Track
Created:	11-Jan-2001
Python-Version:	2.2
Post-History:	21-Mar-2001

Rejection Notice

    I'm rejecting this PEP.  It's been five years now.  While at some
    point I expect that Python will have interfaces, it would be naive
    to expect it to resemble the syntax in this PEP.  Also, PEP 246 is
    being rejected in favor of something completely different; interfaces
    won't play a role in adaptation or whatever will replace it.  GvR.

Introduction

    This PEP describes a proposed syntax for creating interface
    objects in Python.

Overview

    In addition to thinking about adding a static type system to
    Python, the Types-SIG was also charged to devise an interface
    system for Python.  In December of 1998, Jim Fulton released a
    prototype interfaces system based on discussions from the SIG.
    Many of the issues and background information on this discussion
    and prototype can be found in the SIG archives[1].

    Around the end of 2000, Digital Creations began thinking about
    better component model designs for Zope[2].  Zope's future
    component model relies heavily on interface objects.  This led to
    further development of Jim's "Scarecrow" interfaces prototype.
    Starting with version 2.3, Zope comes with an Interface package as
    standard software.  Zope's Interface package is used as the
    reference implementation for this PEP.

    The syntax proposed by this PEP relies on syntax enhancements
    describe in PEP 232 [3] and describes an underlying framework
    which PEP 233 [4] could be based upon.  There is some work being
    done with regard to interface objects and Proxy objects, so for
    those optional parts of this PEP you may want to see[5].

The Problem

    Interfaces are important because they solve a number of problems
    that arise while developing software:

    - There are many implied interfaces in Python, commonly referred
      to as "protocols".  Currently determining those protocols is
      based on implementation introspection, but often that also
      fails.  For example, defining __getitem__ implies both a
      sequence and a mapping (the former with sequential, integer
      keys).  There is no way for the developer to be explict about
      which protocols the object intends to implement.

    - Python is limited, from the developer's point of view, by the
      split between types and classes.  When types are expected, the
      consumer uses code like 'type(foo) == type("")' to determine if
      'foo' is a string.  When instances of classes are expected, the
      consumer uses 'isinstance(foo, MyString)' to determine if 'foo'
      is an instance of the 'MyString' class.  There is no unified
      model for determining if an object can be used in a certain,
      valid way.

    - Python's dynamic typing is very flexible and powerful, but it
      does not have the advantage of static typed languages that
      provide type checking.  Static typed langauges provide you with
      much more type saftey, but are often overly verbose because
      objects can only be generalized by common subclassing and used
      specificly with casting (for example, in Java).

    There are also a number of documentation problems that interfaces
    try to solve.

    - Developers waste a lot of time looking at the source code of
      your system to figure out how objects work.

    - Developers who are new to your system may misunderstand how your
      objects work, causing, and possibly propagating, usage errors.

    - Because a lack of interfaces means usage is inferred from the
      source, developers may end up using methods and attributes that
      are meant for "internal use only".

    - Code inspection can be hard, and very discouraging to novice
      programmers trying to properly understand code written by gurus.

    - A lot of time is wasted when many people try very hard to
      understand obscurity (like undocumented software).  Effort spend
      up front documenting interfaces will save much of this time in
      the end.

    Interfaces try to solve these problems by providing a way for you
    to specify a contractual obligation for your object, documentation
    on how to use an object, and a built-in mechanism for discovering
    the contract and the documentation.

    Python has very useful introspection features.  It is well known
    that this makes exploring concepts in the interactive interpreter
    easier, because Python gives you the ability to look at all kinds
    of information about the objects: the type, doc strings, instance
    dictionaries, base classes, unbound methods and more.

    Many of these features are oriented toward introspecting, using
    and changing the implementation of software, and one of them ("doc
    strings") is oriented toward providing documentation.  This
    proposal describes an extension to this natural introspection
    framework that describes an object's interface.

Overview of the Interface Syntax

    For the most part, the syntax of interfaces is very much like the
    syntax of classes, but future needs, or needs brought up in
    discussion, may define new possibilities for interface syntax.

    A formal BNF description of the syntax is givena later in the PEP,
    for the purposes of illustration, here is an example of two
    different interfaces created with the proposed syntax:

        interface CountFishInterface:
            "Fish counting interface"

            def oneFish():
                "Increments the fish count by one"

            def twoFish():
                "Increments the fish count by two"

            def getFishCount():
                "Returns the fish count"

        interface ColorFishInterface:
            "Fish coloring interface"

            def redFish():
                "Sets the current fish color to red"

            def blueFish():
                "Sets the current fish color to blue"

            def getFishColor():
                "This returns the current fish color" 

    This code, when evaluated, will create two interfaces called
    `CountFishInterface' and `ColorFishInterface'. These interfaces
    are defined by the `interface' statement.

    The prose documentation for the interfaces and their methods come
    from doc strings.  The method signature information comes from the
    signatures of the `def' statements.  Notice how there is no body
    for the def statements.  The interface does not implement a
    service to anything; it merely describes one.  Documentation
    strings on interfaces and interface methods are mandatory, a
    'pass' statement cannot be provided.  The interface equivalent of
    a pass statement is an empty doc string.

    You can also create interfaces that "extend" other interfaces.
    Here, you can see a new type of Interface that extends the
    CountFishInterface and ColorFishInterface:

        interface FishMarketInterface(CountFishInterface, ColorFishInterface):
            "This is the documentation for the FishMarketInterface"

            def getFishMonger():
                "Returns the fish monger you can interact with"

            def hireNewFishMonger(name):
                "Hire a new fish monger"

            def buySomeFish(quantity=1):
                "Buy some fish at the market"

    The FishMarketInteface extends upon the CountFishInterface and
    ColorfishInterface.

更多内容参加原帖。

原帖地址 http://www.python.org/dev/peps/pep-0245/