Claim PEP 3119 for the ABC PEP. Please disregard the contents for now.

pep-0000.txt

@@ -117,6 +117,7 @@ Index by Category
  S  3116  New I/O                                      Stutzbach, Verdone, GvR
  S  3117  Postfix Type Declarations                    Brandl
  S  3118  Revising the buffer protocol                 Oliphant, Banks
+ S  3119  Introducing Abstract Base Classes            GvR, Talin
 
  Finished PEPs (done, implemented in Subversion)
 
@@ -471,6 +472,7 @@ Numerical Index
  S  3116  New I/O                                      Stutzbach, Verdone, GvR
  S  3117  Postfix Type Declarations                    Brandl
  S  3118  Revising the buffer protocol                 Oliphant, Banks
+ S  3119  Introducing Abstract Base Classes            GvR, Talin
 
 
 Key

pep-3119.txt

@@ -0,0 +1,108 @@
+PEP: 3119
+Title: Introducing Abstract Base Classes
+Version: $Revision$
+Last-Modified: $Date$
+Author: Guido van Rossum <guido@python.org>, Talin
+Status: Draft
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 18-Apr-2007
+Post-History: 18-Apr-2007
+
+
+Abstract
+========
+
+This is a proposal to add Abstract Base Class support to Python 3000.
+
+
+Rationale
+=========
+
+In the domain of object-oriented programming, the usage patterns for 
+interacting with an object can be divided into two basic categories, 
+which are 'invocation' and 'inspection'.
+
+Invocation means interacting with an object by invoking its methods. 
+Usually this is combined with polymorphism, so that invoking a given 
+method may run different code depending on the type of an object.
+
+Inspection means the ability for external code (outside of the object's 
+methods) to examine the type or properties of that object, and make 
+decisions on how to treat that object based on that information.
+
+Both usage patterns serve the same general end, which is to be able to 
+support the processing of diverse and potentially novel objects in a 
+uniform way, but at the same time allowing processing decisions to be 
+customized for each different type of object.
+
+In classical OOP theory, invocation is the preferred usage pattern, and 
+inspection is actively discouraged, being considered a relic of an 
+earlier, procedural programming style. However, in practice this view is 
+simply too dogmatic and inflexible, and leads to a kind of design 
+rigidity that is very much at odds with the dynamic nature of a language 
+like Python.
+
+In particular, there is often a need to process objects in a way that 
+wasn't anticipated by the creator of the object class. It is not always 
+the best solution to build in to every object methods that satisfy the 
+needs of every possible user of that object. Moreover, there are many 
+powerful dispatch philosophies that are in direct contrast to the 
+classic OOP requirement of behavior being strictly encapsulated within 
+an object, examples being rule or pattern-match driven logic.
+
+On the the other hand, one of the criticisms of inspection by classic 
+OOP theorists is the lack of formalisms and the ad hoc nature of what is 
+being inspected. In a language such as Python, in which almost any 
+aspect of an object can be reflected and directly accessed by external 
+code, there are many different ways to test whether an object conforms 
+to a particular protocol or not. For example, if asking 'is this object 
+a mutable sequence container?', one can look for a base class of 'list', 
+or one can look for a method named '__getitem__'. But note that although 
+these tests may seem obvious, neither of them are correct, as one 
+generates false negatives, and the other false positives.
+
+The generally agreed-upon remedy is to standardize the tests, and group 
+them into a formal arrangement. This is most easily done by associating 
+with each class a set of standard testable properties, either via the 
+inheritance mechanism or some other means. Each test carries with it a 
+set of promises: it contains a promise about the general behavior of the 
+class, and a promise as to what other class methods will be available.
+
+This PEP proposes a particular strategy for organizing these tests known 
+as Abstract Base Classes, or ABC. ABCs are simply Python classes that 
+are added into an object's inheritance tree to signal certain features 
+of that object to an external inspector. Tests are done using 
+isinstance(), and the presence of a particular ABC means that the test 
+has passed.
+
+Like all other things in Python, these promises are in the nature of a 
+gentlemen's agreement - which means that the language does not attempt 
+to enforce that these promises are kept.
+
+
+References
+==========
+
+.. [1] An Introduction to ABC's, by Talin
+   (http://mail.python.org/pipermail/python-3000/2007-April/006614.html)
+
+.. [2] Incomplete implementation prototype, by GvR
+   (http://svn.python.org/view/sandbox/trunk/abc/)
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: