[Types-sig] First release (0.80) of BWCTO Interface package

Bob Weiner bob@deepware.com
Mon, 26 Mar 2001 20:22:50 -0800 (PST)

Hi all:

I've just today joined the types-sig but I've read much of the
last month of dialogue.  It is great to see that Michel Pelletier
has rolled up much of the work done at Digital Creations' on
Python interfaces into PEP-245 for community discussion and
evolution.  Right now, I think, an ability to enforce (where
desired) interface conformance will do much more to enable Python
to be used for rapid system development on larger projects than
static typing extensions would (based on my experience with
Python and many other static and dynamic languages).

In November of last year I had some time independently to develop
a first-pass implementation of interfaces for Python, but since
that time have not had time to work on it.  The release of
PEP-245 motivated me to put the time necessary to produce a
useful 0.8 release of what I've called BWCTO Interface just to
give it a distinguishing name; this is a fully working release
which just lacks a few features.  I hope people will look at the
design and the code, try it out and consider leveraging some of
it in the ongoing interface extension work for Python.  I tend to
focus on design and documentation in my software, so
stylistically at least it may be worth a look.  If you have
questions about it, I would ask that you write down a list of
your questions and then post a single message with them; this
will allow me to respond most efficiently to such queries and
potentially participate regularly in the dialogue on this list.

If someone wants to take over maintenance towards a 1.0 release
or if this can be merged with Digital Creations' Interface work,
I can provide pointers about what else needs to be done.

Get the package from:

Below is the README file included in this distribution.

If this is worthy of the Python-announce list, please feel free
to repost this message there.



# SUMMARY:      Overview of the BWCTO Interface package and remaining issues
# AUTHOR:       Bob Weiner
# E-MAIL:       bwcto at yahoo.com
# ORIG-DATE:    26-Mar-01 at 11:49:31 by Bob Weiner
# LAST-MOD:     26-Mar-01 at 22:41:27 by Bob Weiner
# COPYRIGHT:    Copyright (C) 2001  Bob Weiner
# LICENSE:      Available under the terms of the Python Open Source License 2.0
or higher.
# This package is called BWCTO Interfaces to distinguish it from any
# other ongoing Python Interface work.  If integrated with core
# Python, it could simply be called the Interface package.
# This package was designed and implemented in November and December
# 2000 without reference to any other ongoing Interface work.  In
# March 2001, I looked at the Python type-sig mailing list archives
# and the Interface PEP-245 and decided to finalize this enough to
# share with the Python community for use in any ongoing interface
# development efforts.
# See the documentation in "interface.py" for how this package
# works and for version information.  See "getset.py" for a simple
# interface definition which can also be tested by running: python
# getset.py.  See "instantiable.py" for basic instance-oriented
# interfaces.  Indexable collection interfaces are in a primitive
# state of development and so are not included in this release.
# Places in the code marked with !!! indicate key areas of remaining
# work.
# This package was implemented to see if Python could scale to large
# multi-party system implementations where contractual enforcement
# of public interface specifications is critical to both the
# development and quality assurance cycles.  It was also implemented
# as an exercise in strong documentation and error reporting
# techniques, so feel free to emulate the styles herein or to
# suggest improvements.
# For completeness of attribution, please note that many of the
# documentation strings within the included interfaces are derived
# from the standard Python library documentation.

* Todos

** Turn this into a proper self-installing Python package or get it
   implemented as part of the core of the language as described in

** Turn over lead development to another party.

** See if the BWCTO Interface implementation can be meshed with
   Digital Creations' independent Interface implementation and
   Michel Pelletier's PEP-245 on Interfaces.  The two specifications
   and implementations are relatively close but have a number of
   differences which would need to be resolved via the PEP process:

     BWCTO Interfaces has a simpler Interface inheritance structure
     and a simpler set of core interface handling functions.

     BWCTO Interfaces allow for implementation inheritance where
     appropriate whereas D.C. Interfaces view this mixing of
     interface conformance and algorithmic implementation as
     undesirable behavior.  Since all methods listed in a
     D.C. interface are stubs (deferred methods), there is no need
     to differentiate these explicitly from implemented methods.
     In BWCTO Interfaces, using a first argument of `iself' declares
     the method to be a stub.  (If integrated with core Python,
     a new type of def keyword such as `stub' would be used to
     enforce these semantics.)

     PEP-245 V1.3 states that "Interfaces can extend other
     interfaces, but they do not share the contractual
     responsibility of the interfaces they extend."  On this basis,
     if Interface B extends Interface A, it does not publish the
     method stub names from Interface A; instead it uses a special
     "names" methods to reference these.  BWCTO uses traditional
     Python inheritance semantics in such cases to minimize the
     learning and utility curve of interfaces.

     BWCTO Interfaces can embed pre- and post-conditions within
     Interface method stubs.  D.C. Interfaces cannot do this since
     they don't support deferred method bodies; instead they require
     separate pre- and post-condition definitions via use of the new
     function attribute feature in Python which means standard
     method definition syntax cannot be used.

     BWCTO Interfaces lacks the "Tagging Interface Elements" feature
     described in PEP-245, though there is no barrier to integration
     of such support with this package.

     PEP-245 uses the terminology "interface assertion" to describe
     the explicit set of interfaces listed in a class definition to
     which the class is said to conform.  BWCTO Interfaces provides
     a full set of functions which allow one to query both classes
     and interfaces uniformly for the interfaces which they support
     or to separately use the "extends" and "implements" functions
     to differentiate extension (interfaces extending other
     interfaces) from implementation (classes implementing

     PEP-245 allows programmers to reference the __implements__
     attribute of class A to allow class B to implement the
     same set of interfaces listed therein.  BWCTO Interfaces does
     not have this feature.  This is a good idea but for readability
     in such usages, __interfaces__ would be a better name.

I am glad to see Michel pursuing a PEP on Interfaces since I was
interested in contributing my own Interface work to the community
and helping to make Interfaces a standard part of future Python
releases.  I no longer have the time to put into actively working on
this however, so I am willing to turn this over to Michel or others
who want to work on a single unified Interface specification and
implementation for Python.  I will be happy to participate in the
discussions on PEP-245 and to assist in creating a single unified
Interface design for Python as time allows.  Feedback on the code
and interface specification style are welcome as I'm sure
improvements can be made.


Bob Weiner
bwcto at yahoo.com (personal address)
bob at deepware.com (work address)