[Python-checkins] r54880 - peps/trunk/pep-3119.txt (original) (raw)

guido.van.rossum python-checkins at python.org
Thu Apr 19 23:50:05 CEST 2007

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 containsmethod returnsFalse. **Invariant:** If a class Cderives fromContaineras 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 instanceoofC. 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

More information about the Python-checkins mailing list