[Python-checkins] r54880 - peps/trunk/pep-3119.txt

[guido.van.rossum]

Author: guido.van.rossum
Date: Thu Apr 19 23:49:59 2007
New Revision: 54880

Modified:
   peps/trunk/pep-3119.txt
Log:
Added some comparisons to other ideas, open issues, and more references.


Modified: peps/trunk/pep-3119.txt
==============================================================================
--- peps/trunk/pep-3119.txt	(original)
+++ peps/trunk/pep-3119.txt	Thu Apr 19 23:49:59 2007
@@ -36,6 +36,14 @@
 makes a set", "what makes a mapping" and "what makes a sequence".
 
 
+Acknowledgements
+----------------
+
+Talin wrote the Rationale below [1]_.  For that alone he deserves
+co-authorship.  But the rest of the PEP uses "I" referring to the
+first author.
+
+
 Rationale
 =========
 
@@ -195,7 +203,6 @@
 it has two prescribed methods.
 
 ``Hashable``
-
     The base class for classes defining ``__hash__``.  The
     ``__hash__`` method should return an ``Integer`` (see "Numbers"
     below).  The abstract ``__hash__`` method always returns 0, which
@@ -233,7 +240,7 @@
     ``__contains__` method should return a ``bool``.` The abstract
     ``__contains__`` method returns ``False``.  **Invariant:** If a
     class ``C`` derives from ``Container`` as well as from
-    ``Iterable``, ``(x in o for x in o)`` should be a generator
+    ``Iterable``, then ``(x in o for x in o)`` should be a generator
     yielding only True values for any instance ``o`` of ``C``.
 
     Note: strictly speaking, there are three variants of this method's
@@ -326,7 +333,6 @@
     values for different types of numbers and strings.)
 
 ``MutableSet``
-
     This is a subclass of ``Set`` implementing additional operations
     to add and remove elements.  The supported methods have the
     semantics known from the ``set`` type in Python 2:
@@ -466,17 +472,119 @@
 
 XXX define: Number, Complex, Real, Rational, Integer.  Do we have a
 use case for Cardinal (Integer >= 0)?  Do we need Indexable (converts
-to Integer using __index__).
+to Integer using __index__)?  Or is that just subsumed into Integer
+and should we use __index__ only at the C level?
 
 
 Guidelines for Writing ABCs
 ---------------------------
 
-XXX Use @abstractmethod and Abstract base class; define abstract
-methods that could be useful as an end point when called via a super
-chain; define concrete methods that are very simple permutations of
-abstract methods (e.g. Mapping.get); keep abstract classes small, one
-per use case instead of one per concept.
+Some sugegstions:
+
+* Use @abstractmethod and Abstract base class.
+
+* Define abstract methods that could be useful as an end point when
+  called via a super chain.
+
+* Define concrete methods that are very simple permutations of
+  abstract methods (e.g. Mapping.get).
+
+* Keep abstract classes small, one per use case instead of one per
+  concept.
+
+* XXX What else?
+
+
+ABCs vs. Alternatives
+=====================
+
+In this section I will attempt to compare and contrast ABCs to other
+approaches that have been proposed.
+
+
+ABCs vs. Duck Typing
+--------------------
+
+Does the introduction of ABCs mean the end of Duck Typing?  I don't
+think so.  Python will not require that a class derives from
+``BasicMapping`` or ``Sequence`` when it defines a ``__getitem__``
+method, nor will the ``x[y]`` syntax require that ``x`` is an instance
+of either ABC.  You will still be able to assign any "file-like"
+object to ``sys.stdout``, as long as it has a ``write`` method.
+
+Of course, there will be some carrots to encourage users to derive
+from the appropriate base classes; these vary from default
+implementations for certain functionality to an improved ability to
+distinguish between mappings and sequences.  But there are no sticks.
+If ``hasattr(x, __len__)`` works for you, great!  ABCs are intended to
+solve problems that don't have a good solution at all in Python 2,
+such as distinguishing between mappings and sequences.
+
+
+ABCs vs. Generic Functions
+--------------------------
+
+ABCs are compatible with Generic Functions (GFs).  For example, my own
+Generic Functions implementation [4]_ uses the classes (types) of the
+arguments as the dispatch key, allowing derived classes to override
+base classes.  Since (from Python's perspective) ABCs are quite
+ordinary classes, using an ABC in the default implementation for a GF
+can be quite appropriate.  For example, if I have an overloaded
+``prettyprint`` function, it would make total sense to define
+pretty-printing of sets like this::
+
+    @prettyprint.register(Set)
+    def pp_set(s):
+        return "{" + ... + "}"  # Details left as an exercise
+
+and implementations for specific subclasses of Set could be added
+easily.  
+
+I believe ABCs also won't present any problems for RuleDispatch,
+Phillip Eby's GF implementation in PEAK [5]_.
+
+Of course, GF proponents might claim that GFs (and concrete, or
+implementation, classes) are all you need.  But even they will not
+deny the usefulness of inheritance; and one can easily consider the
+ABCs proposed in this PEP as optional implementation base classes;
+there is no requirement that all user-defined mappings derive from
+``BasicMapping``.
+
+
+ABCs vs. Interfaces
+-------------------
+
+ABCs are not intrinsically incompatible with Interfaces, but there is
+considerable overlap.  For now, I'll leave it to proponents of
+Interfaces to explain why Interfaces are better.  I expect that much
+of the work that went into e.g. defining the various shades of
+"mapping-ness" and the nomenclature could easily be adapted for a
+proposal to use Interfaces instead of ABCs.
+
+
+Open Issues
+===========
+
+Apart from the open issues already sprinkled through the text above,
+and the "category one" issue of deciding between ABCs, GFs and
+Interfaces there are some fairly large looming issues.
+
+* Should we strive to use ABCs for *all* areas of Python?  The wiki
+  page for ABCs created by Bill Janssen [3]_ tries to be
+  comprehensive: it defines everything from Comparable and Object to
+  files.  The current PEP tries to limit itself to three areas: ABC
+  support (like the ``@abstractmethod`` decorator), collections types,
+  and numbers.  The proposed class hierarchy for new I/O described in
+  PEP 3116 already including de-facto ABCs; these can easily be
+  upgraded to use the mechanisms from the current PEP if it is
+  accepted.  Perhaps Orderable would be a good concept to define
+  in the current PEP; I don't expect we need to go further.
+
+* Perhaps the numeric classes could be moved to a separate PEP; the
+  issues there don't have much in common with the issues for
+  collection types.
+
+* XXX What else?
 
 
 References
@@ -488,6 +596,16 @@
 .. [2] Incomplete implementation prototype, by GvR
    (http://svn.python.org/view/sandbox/trunk/abc/)
 
+.. [3] Possible Python 3K Class Tree?, wiki page created by Bill Janssen
+   (http://wiki.python.org/moin/AbstractBaseClasses)
+
+.. [4] Generic Functions implementation, by GvR
+   (http://svn.python.org/view/sandbox/trunk/overload/)
+
+.. [5] Charming Python: Scaling a new PEAK, by David Mertz
+   (http://www-128.ibm.com/developerworks/library/l-cppeak2/)
+
+
 
 Copyright
 =========