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.


-- Juanca

On Sat Nov 15 2014 at 1:50:06 PM Steve Dower <Steve.Dower@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.)


Top-posted from my Windows Phone

From: Chris Angelico
Sent: ‎11/‎15/‎2014 1:30
To: python-ideas
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@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


This PEP proposes a semantic change to ``StopIteration`` when raised
inside a generator, unifying the behaviour of list comprehensions and
generator expressions somewhat.


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.


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.


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.


.. [1] Initial mailing list comment

.. [2] Pure Python implementation of groupby

.. [3] Proposal by GvR

.. [4] Response by Steven D'Aprano


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
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/