From the StopIteration-in-generators handling transition plan (https://www.python.org/dev/peps/pep-0479/#transition-plan):

• Python 3.5: Enable new semantics under __future__ import; silent deprecation warning if StopIteration bubbles out of a generator not under __future__ import.

The first half of that was implemented in bpo-22906, but we missed the second half.

The reason the latter is needed is so that people can turn the DeprecationWarning into an error to test for compatibility with the future default behaviour without needing to add the new future flag to their code (which would break compatibility with older Python versions). Ram Rachum pointed out the absence on python-ideas: https://mail.python.org/pipermail/python-ideas/2015-May/033580.html

Nick, please review the patch.

BTW, we will have *a lot* of warnings now when running tests with -Wall. Are we going to employ "from __future__ import generator_stop" everywhere in 3.5?

Given the two-release deprecation cycle, would it be worth using PendingDeprecationWarning here? That way folks that only turned on DeprecationWarning (rather than -Wall) wouldn't need to worry about this until 3.6.

As far as our own test suite goes, when ResourceWarning was introduced, dealing with those in the test suite became an ongoing cleanup task. Are there really all that many warnings triggered for PEP-479?

Had to regenerate the patch. Fixed some typos + now I use PyErr_WriteUnraisable if PyErr_WarnFormat returns non-zero.

And yeah, PendingDeprecationWarning is a better choice.

Are there really all that many warnings triggered for PEP-479?

Actually, with the attached patch the number of warnings is pretty low, we can definitely fix/silence them where necessary. (I think I had a bug in one of my first patches that triggered some false-positives).

• test_difflib - will have to fix difflib;

• test_contextlib - tests StopIteration propagation on purpose; will silence the warning;

• test_with

• test_generators

Why the switch to WriteUnraisable? Unlike __del__ methods and similar operations that may be invoked at arbitrary points, there's nothing stopping us from emitting an exception here - indeed, we're *already* handling an exception.

Getting a hard failure on deprecations is one of the expected consequences of using "-Wall" rather than the default settings.

Why the switch to WriteUnraisable?

After adding a unittest for the patch it became clear that it was indeed unnecessary ;) Please see the new patch.

Nick, I've updated the patch to address all PendingDeprecationWarnings related to the PEP-479 in the test suite.

The patch mostly looks good to me, but I suggest using "test.support.check_warnings" for the cases where you're checking that the warning is raised as expected: https://docs.python.org/3/library/test.html#test.support.check_warnings

It's slightly simpler than constructing the same logic yourself using warnings.catch_warnings.

Another alternative is using assertWarnsRegex.

New changeset 2771a0ac806b by Yury Selivanov in branch 'default':
bpo-24237: Raise PendingDeprecationWarning per PEP-479
https://hg.python.org/cpython/rev/2771a0ac806b

Nick, I updated the code to use assertWarnsRegex (thanks for suggestion, Berker!)

Closing the issue.