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
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
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
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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/