On 19 May 2015 at 13:15, Steven D'Aprano
So, I believe that the whole __future__ directive is a red herring, and doesn't actually help Ram do what he wants, which is to write tests which will fail if his generators call raise StopIteration regardless of what version of Python he runs the test under.
The essential impossibility of writing such tests is one of the underlying reasons *why* PEP 479 was accepted - you can't sensibly test for inadvertently escaping StopIteration values. However, I interpreted Ram's request slightly differently: if I'm understanding the request correctly, he'd like a way to write single-source modules such that *on Python 3.5+* they effectively run with "from __future__ import generator_stop", while on older Python versions, they run unmodified. That way, running the test suite under Python 3.5 will show that at least the regression tests aren't relying on "escaping StopIteration" in order to pass. The intended answer to Ram's request is "configure the warnings module to turn the otherwise silent deprecation warning into an error". From 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. However, we missed the second half of that in the initial PEP implementation, so it doesn't currently emit the deprecation warning at all, which means there's no way to turn it into an error instead: http://bugs.python.org/issue24237 Once that issue has been fixed, then "-Wall" will cause any tests relying on the deprecated behaviour to fail, *without* needing to modify the code under test to use the future import. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia