[Python-checkins] peps: Accept PEP 443, making a few minor edits to improve text flow.

guido.van.rossum python-checkins at python.org
Wed Jun 5 03:29:57 CEST 2013


http://hg.python.org/peps/rev/38826efc5fe4
changeset:   4921:38826efc5fe4
user:        Guido van Rossum <guido at python.org>
date:        Tue Jun 04 18:29:49 2013 -0700
summary:
  Accept PEP 443, making a few minor edits to improve text flow.

files:
  pep-0443.txt |  27 +++++++++++++++------------
  1 files changed, 15 insertions(+), 12 deletions(-)


diff --git a/pep-0443.txt b/pep-0443.txt
--- a/pep-0443.txt
+++ b/pep-0443.txt
@@ -4,7 +4,7 @@
 Last-Modified: $Date$
 Author: Łukasz Langa <lukasz at langa.pl>
 Discussions-To: Python-Dev <python-dev at python.org>
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 22-May-2013
@@ -44,11 +44,14 @@
 
 In addition, it is currently a common anti-pattern for Python code to
 inspect the types of received arguments, in order to decide what to do
-with the objects. For example, code may wish to accept either an object
+with the objects.
+
+For example, code may wish to accept either an object
 of some type, or a sequence of objects of that type.
+Currently, the "obvious way" to do this is by type inspection, but this
+is brittle and closed to extension.
 
-Currently, the "obvious way" to do this is by type inspection, but this
-is brittle and closed to extension. Abstract Base Classes make it easier
+Abstract Base Classes make it easier
 to discover present behaviour, but don't help adding new behaviour.
 A developer using an already-written library may be unable to change how
 their objects are treated by such code, especially if the objects they
@@ -63,7 +66,7 @@
 
 To define a generic function, decorate it with the ``@singledispatch``
 decorator. Note that the dispatch happens on the type of the first
-argument, create your function accordingly::
+argument. Create your function accordingly::
 
   >>> from functools import singledispatch
   >>> @singledispatch
@@ -73,7 +76,7 @@
   ...     print(arg)
 
 To add overloaded implementations to the function, use the
-``register()`` attribute of the generic function. It is a decorator,
+``register()`` attribute of the generic function. This is a decorator,
 taking a type parameter and decorating a function implementing the
 operation for that type::
 
@@ -98,7 +101,7 @@
   ...
   >>> fun.register(type(None), nothing)
 
-The ``register()`` attribute returns the undecorated function which
+The ``register()`` attribute returns the undecorated function. This
 enables decorator stacking, pickling, as well as creating unit tests for
 each variant independently::
 
@@ -172,12 +175,12 @@
 reference implementation is available on hg.python.org [#ref-impl]_.
 
 The dispatch type is specified as a decorator argument. An alternative
-form using function annotations has been considered but its inclusion
-has been deferred. As of May 2013, this usage pattern is out of scope
-for the standard library [#pep-0008]_ and the best practices for
+form using function annotations was considered but its inclusion
+has been rejected. As of May 2013, this usage pattern is out of scope
+for the standard library [#pep-0008]_, and the best practices for
 annotation usage are still debated.
 
-Based on the current ``pkgutil.simplegeneric`` implementation and
+Based on the current ``pkgutil.simplegeneric`` implementation, and
 following the convention on registering virtual subclasses on Abstract
 Base Classes, the dispatch registry will not be thread-safe.
 
@@ -278,7 +281,7 @@
 
 This PEP proposes extending behaviour only of functions specifically
 marked as generic. Just as a base class method may be overridden by
-a subclass, so too may a function be overloaded to provide custom
+a subclass, so too a function may be overloaded to provide custom
 functionality for a given type.
 
 Universal overloading does not equal *arbitrary* overloading, in the

-- 
Repository URL: http://hg.python.org/peps


More information about the Python-checkins mailing list