[Python-checkins] peps: Reorder/renumber footnotes in PEP 479 and insert one for the tracker issue

chris.angelico python-checkins at python.org
Sat Dec 6 17:12:25 CET 2014


https://hg.python.org/peps/rev/bcf0e3459196
changeset:   5636:bcf0e3459196
user:        Chris Angelico <rosuav at gmail.com>
date:        Sun Dec 07 03:12:17 2014 +1100
summary:
  Reorder/renumber footnotes in PEP 479 and insert one for the tracker issue

files:
  pep-0479.txt |  46 ++++++++++++++++++++-------------------
  1 files changed, 24 insertions(+), 22 deletions(-)


diff --git a/pep-0479.txt b/pep-0479.txt
--- a/pep-0479.txt
+++ b/pep-0479.txt
@@ -158,7 +158,7 @@
 If a ``StopIteration`` is about to bubble out of a generator frame, it
 is replaced with ``RuntimeError``, which causes the ``next()`` call
 (which invoked the generator) to fail, passing that exception out.
-From then on it's just like any old exception. [4]_
+From then on it's just like any old exception. [3]_
 
 This affects the third outcome listed above, without altering any
 other effects.  Furthermore, it only affects this outcome when the
@@ -194,13 +194,15 @@
 proposal.  Once the feature becomes standard, the flag may be dropped;
 code should not inspect generators for it.
 
+A proof-of-concept patch has been created to facilitate testing. [4]_
+
 
 Consequences for existing code
 ==============================
 
 This change will affect existing code that depends on
 ``StopIteration`` bubbling up.  The pure Python reference
-implementation of ``groupby`` [3]_ currently has comments "Exit on
+implementation of ``groupby`` [5]_ currently has comments "Exit on
 ``StopIteration``" where it is expected that the exception will
 propagate and then be handled.  This will be unusual, but not unknown,
 and such constructs will fail.  Other examples abound, e.g. [6]_, [7]_.
@@ -474,7 +476,7 @@
 Converting the exception inside next()
 --------------------------------------
 
-Mark Shannon suggested [12]_ that the problem could be solved in
+Mark Shannon suggested [10]_ that the problem could be solved in
 ``next()`` rather than at the boundary of generator functions.  By
 having ``next()`` catch ``StopIteration`` and raise instead
 ``ValueError``, all unexpected ``StopIteration`` bubbling would be
@@ -490,7 +492,7 @@
 Sub-proposal: decorator to explicitly request current behaviour
 ---------------------------------------------------------------
 
-Nick Coghlan suggested [13]_ that the situations where the current
+Nick Coghlan suggested [11]_ that the situations where the current
 behaviour is desired could be supported by means of a decorator::
 
     from itertools import allow_implicit_stop
@@ -523,18 +525,18 @@
 compatibility issues created, the subtlety of the decorator's effect,
 and the fact that it would encourage the "quick-fix" solution of just
 slapping the decorator onto all generators instead of properly fixing
-the code in question, this sub-proposal has been rejected. [14]_
+the code in question, this sub-proposal has been rejected. [12]_
 
 
 Criticism
 =========
 
 Unofficial and apocryphal statistics suggest that this is seldom, if
-ever, a problem. [5]_  Code does exist which relies on the current
+ever, a problem. [13]_  Code does exist which relies on the current
 behaviour (e.g. [3]_, [6]_, [7]_), and there is the concern that this
 would be unnecessary code churn to achieve little or no gain.
 
-Steven D'Aprano started an informal survey on comp.lang.python [10]_;
+Steven D'Aprano started an informal survey on comp.lang.python [14]_;
 at the time of writing only two responses have been received: one was
 in favor of changing list comprehensions to match generator
 expressions (!), the other was in favor of this PEP's main proposal.
@@ -563,14 +565,14 @@
 .. [2] Initial mailing list comment
    (https://mail.python.org/pipermail/python-ideas/2014-November/029906.html)
 
-.. [3] Pure Python implementation of groupby
-   (https://docs.python.org/3/library/itertools.html#itertools.groupby)
-
-.. [4] Proposal by GvR
+.. [3] Proposal by GvR
    (https://mail.python.org/pipermail/python-ideas/2014-November/029953.html)
 
-.. [5] Response by Steven D'Aprano
-   (https://mail.python.org/pipermail/python-ideas/2014-November/029994.html)
+.. [4] Tracker issue with Proof-of-Concept patch
+   (http://bugs.python.org/issue22906)
+
+.. [5] Pure Python implementation of groupby
+   (https://docs.python.org/3/library/itertools.html#itertools.groupby)
 
 .. [6] Split a sequence or generator using a predicate
    (http://code.activestate.com/recipes/578416-split-a-sequence-or-generator-using-a-predicate/)
@@ -584,21 +586,21 @@
 .. [9] Coroutines in asyncio
    (https://docs.python.org/3/library/asyncio-task.html#coroutines)
 
-.. [10] Thread on comp.lang.python started by Steven D'Aprano
-   (https://mail.python.org/pipermail/python-list/2014-November/680757.html)
-
-.. [11] Tracker issue with Proof-of-Concept patch
-   (http://bugs.python.org/issue22906)
-
-.. [12] Post from Mark Shannon with alternate proposal
+.. [10] Post from Mark Shannon with alternate proposal
    (https://mail.python.org/pipermail/python-dev/2014-November/137129.html)
 
-.. [13] Idea from Nick Coghlan
+.. [11] Idea from Nick Coghlan
    (https://mail.python.org/pipermail/python-dev/2014-November/137201.html)
 
-.. [14] Rejection by GvR
+.. [12] Rejection of above idea by GvR
    (https://mail.python.org/pipermail/python-dev/2014-November/137243.html)
 
+.. [13] Response by Steven D'Aprano
+   (https://mail.python.org/pipermail/python-ideas/2014-November/029994.html)
+
+.. [14] Thread on comp.lang.python started by Steven D'Aprano
+   (https://mail.python.org/pipermail/python-list/2014-November/680757.html)
+
 Copyright
 =========
 

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


More information about the Python-checkins mailing list