Two new sections (more motivation, rejected @allow_implicit_stop).

pep-0479.txt

@@ -100,6 +100,16 @@ Finally, the proposal also clears up the confusion about how to
 terminate a generator: the proper way is ``return``, not
 ``raise StopIteration``.
 
+As an added bonus, the above changes bring generator functions much
+more in line with regular functions.  If you wish to take a piece of
+code presented as a generator and turn it into something else, you
+can usually do this fairly simply, by replacing every ``yield`` with
+a call to ``print()`` or ``list.append()``; however, if there are any
+bare ``next()`` calls in the code, you have to be aware of them.  If
+the code was originally written without relying on ``StopIteration``
+terminating the function, the transformation would be that much
+easier.
+
 
 Background information
 ======================
@@ -433,6 +443,7 @@ another generator and relies on the latter's ``StopIteration`` to
 bubble out would still be potentially wrong, depending on the use made
 of the distinction between the two exception types.
 
+
 Converting the exception inside next()
 --------------------------------------
 
@@ -449,6 +460,45 @@ block of code which reliably works on multiple versions of Python.
 would help this; however, all code would still need to be rewritten.)
 
 
+Sub-proposal: decorator to explicitly request current behaviour
+---------------------------------------------------------------
+
+Nick Coghlan suggested [13]_ that the situations where the current
+behaviour is desired could be supported by means of a decorator::
+
+    from itertools import allow_implicit_stop
+
+    @allow_implicit_stop
+    def my_generator():
+        ...
+        yield next(it)
+        ...
+
+Which would be semantically equivalent to::
+
+    def my_generator():
+        try:
+            ...
+            yield next(it)
+            ...
+        except StopIteration
+            return
+
+but be faster, as it could be implemented by simply permitting the
+``StopIteration`` to bubble up directly.
+
+Single-source Python 2/3 code would also benefit in a 3.7+ world,
+since libraries like six and python-future could just define their own
+version of "allow_implicit_stop" that referred to the new builtin in
+3.5+, and was implemented as an identity function in other versions.
+
+However, due to the implementation complexities required, the ongoing
+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]_
+
+
 Criticism
 =========
 
@@ -516,6 +566,12 @@ References
 .. [12] Post from Mark Shannon with alternate proposal
    (https://mail.python.org/pipermail/python-dev/2014-November/137129.html)
 
+.. [13] Idea from Nick Coghlan
+   (https://mail.python.org/pipermail/python-dev/2014-November/137201.html)
+
+.. [14] Rejection by GvR
+   (https://mail.python.org/pipermail/python-dev/2014-November/137243.html)
+
 Copyright
 =========