[Python-ideas] PEP 479: Change StopIteration handling inside generators

[Juancarlo Añez]

Exactly!

The current behavior is not only likely undesirable, but it is also
undocumented.

Even if parts of stdlib rely on the current behavior, there's no need for a
deprecation (read __future__) period.

Undocumented features may change any time, because are mostly about
implementation quirks (Isn't that rule documented somewhere in the Python
docs?).

In short:

-1 deprecation (__future__); no need, because nothing documented gets broken
+1 fix it now (3.5); the fix may be a change in the docs to validate the
current behavior, and deprecate it (Yuk!)
+1 Nick's design, which kind of leaves it the same and kind of fixes it

p.s. What about 2.7? This fix is *not* a new feature.

Cheers,

-- Juanca

On Sat Nov 15 2014 at 1:50:06 PM Steve Dower <Steve.Dower at microsoft.com>
wrote:

>   Since this changes the behavior of an object instance, how can
> __future__ help? If the generator definition is in a library but the code
> that raises StopIteration to terminate it is passed in from the users code,
> how is the user supposed to select the behavior they want? (This sounds to
> me like a similar problem to adding 'from __future__ import py3_string' to
> Py2, which we discussed a while ago. Happy to be shown that it isn't.)
>
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
>  ------------------------------
> From: Chris Angelico <rosuav at gmail.com>
> Sent: ‎11/‎15/‎2014 1:30
> To: python-ideas <python-ideas at python.org>
> Subject: [Python-ideas] PEP 479: Change StopIteration handling inside
> generators
>
>   PEP: 479
> Title: Change StopIteration handling inside generators
> Version: $Revision$
> Last-Modified: $Date$
> Author: Chris Angelico <rosuav at gmail.com>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 15-Nov-2014
> Python-Version: 3.5
> Post-History: 15-Nov-2014
>
>
> Abstract
> ========
>
> This PEP proposes a semantic change to ``StopIteration`` when raised
> inside a generator, unifying the behaviour of list comprehensions and
> generator expressions somewhat.
>
>
> Rationale
> =========
>
> The interaction of generators and ``StopIteration`` is currently
> somewhat surprising, and can conceal obscure bugs.  An unexpected
> exception should not result in subtly altered behaviour, but should
> cause a noisy and easily-debugged traceback.  Currently,
> ``StopIteration`` can be absorbed by the generator construct.
>
>
> Proposal
> ========
>
> If a ``StopIteration`` is about to bubble out of a generator frame, it
> is replaced with some other exception (maybe ``RuntimeError``, maybe a
> new custom ``Exception`` subclass, but *not* deriving from
> ``StopIteration``) 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. [3]_
>
>
> Consequences to existing code
> =============================
>
> This change will affect existing code that depends on
> ``StopIteration`` bubbling up.  The pure Python reference
> implementation of ``groupby`` [1]_ 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.
>
> (Nick Coghlan comments: """If you wanted to factor out a helper
> function that terminated the generator you'd have to do "return
> yield from helper()" rather than just "helper()".""")
>
> As this can break code, it is proposed to utilize the ``__future__``
> mechanism to introduce this, finally making it standard in Python 3.6
> or 3.7.
>
>
> Alternate proposals
> ===================
>
> Supplying a specific exception to raise on return
> -------------------------------------------------
>
> Nick Coghlan suggested a means of providing a specific
> ``StopIteration`` instance to the generator; if any other instance of
> ``StopIteration`` is raised, it is an error, but if that particular
> one is raised, the generator has properly completed.
>
>
> Making return-triggered StopIterations obvious
> ----------------------------------------------
>
> For certain situations, a simpler and fully backward-compatible
> solution may be sufficient: when a generator returns, instead of
> raising ``StopIteration``, it raises a specific subclass of
> ``StopIteration`` which can then be detected.  If it is not that
> subclass, it is an escaping exception rather than a return statement.
>
>
> Criticism
> =========
>
> Unofficial and apocryphal statistics suggest that this is seldom, if
> ever, a problem. [4]_  Code does exist which relies on the current
> behaviour, and there is the concern that this would be unnecessary
> code churn to achieve little or no gain.
>
>
> References
> ==========
>
> .. [1] Initial mailing list comment
>    (
> https://mail.python.org/pipermail/python-ideas/2014-November/029906.html)
>
> .. [2] Pure Python implementation of groupby
>    (https://docs.python.org/3/library/itertools.html#itertools.groupby)
>
> .. [3] Proposal by GvR
>    (
> https://mail.python.org/pipermail/python-ideas/2014-November/029953.html)
>
> .. [4] Response by Steven D'Aprano
>    (
> https://mail.python.org/pipermail/python-ideas/2014-November/029994.html)
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
>
>
> ..
>    Local Variables:
>    mode: indented-text
>    indent-tabs-mode: nil
>    sentence-end-double-space: t
>    fill-column: 70
>    coding: utf-8
>    End:
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>   _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141115/dc045fb8/attachment-0001.html>