[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