[Python-ideas] Making it easy to prepare for PEP479

[Nick Coghlan]

On 19 May 2015 at 13:15, Steven D'Aprano <steve at pearwood.info> wrote:
> 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 at gmail.com   |   Brisbane, Australia