[meta-sig] PROPOSAL: Python Scarecrow SIG

[Jim Fulton]

I propose creation of a new SIG.

Problem

Two of the Fundamental ideas in object oriented development are 

  - separation of object interfaces from object implementation, and 
    
  - ability to use objects with the same interface but different
    implementations interchangeably. 

When used properly, these two features provide many benefits, such as
safety, stability, flexibility, reuse, and so on. 

Unfortunately, most computer languages provide very little support for
reasoning about or testing interfaces. Worse, many languages provide
incomplete or misleading interface information. Compounding the problem
is that commonly used jargon has many and often conflicting interpretations.
For example, the terms "class" and "type" may alternately mean interface or
implementation. Even the term "interface" can have different meanings. For
some, "interface" refers to method signatures, while for others, the term
connotes identical behavior. 

For some time, Python programmers have wanted simple and efficient
means to be able to test object interfaces. For example, a function may be
willing to accept an argument that is either a "number" or a "sequence" and
must be able to test whether the argument is one or the other to decide how
it is used. 

As Python is used for larger projects and in a larger number of domains,
reliability of Python programs is an increasing concern. People would like
language support to help assure program correctness. Python 1.5 adds the
ability to include assertions in programs and recent advances in the ability to
extend class semantics provides the ability to experiment with argument
interface checking and Meyer's "development by contract". 

This subject was discussed at some length in a "Developer's Day Session", 
"Python Interfaces" at the 7th International Python Conference.  

In this session, some basic goals:

  - ability to branch on object behavior,

  - support tools for providing "type safety", 

  - document and organize the behavior of Python classes, 
    both in the standard library and in extensions.

and some basic assumptions (assertions):

  - interfaces are more than just signatures,

  - full conformance checking by the language is
    not practical,

  - Interfaces should be modeled with a separate 
    (inheritance) hierarchy than implementation.

  - Subclassing should *not* require subclasses
    to conform to base class contracts.

were presented and discussed.

Out of this discussion came a straw-person proposal,  dubbed by Skip 
Montanaro, the "Scarecrow Proposal", for a first step in 
implementing/prototyping Python interfaces.

It was decided that a SIG should be formed to implement the Scarecrow 
proposal, resolve jargon issues, develop tools, such as conformance
or interface documentation tools, and work on a more comprehensive
proposal for Python 2.  

It is expected that the Python 2 interfaces proposal may include:

  - syntax enhancements, 

  - built-in conformance checks and other tools, 

  - support for richer interface modeling, such as design by contract, 

  - support for static typing features should they materialize, 

  - etc.
    
I propose that a SIG should be formed with some name like "interface"
or perhaps the more ecumenical, "scarecrow". :)

I volunteer to administer the SIG.

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.