diff --git a/pep-0479.txt b/pep-0479.txt index 22c4499ab..5e28b4e6a 100644 --- a/pep-0479.txt +++ b/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 =========