Coverage report from 4.1b2 is perfect! At least I don't see false positives on run over aiohttp test suite.
On Sun, Jan 24, 2016 at 2:47 AM, Ned Batchelder <[email protected]> wrote: > FWIW, I've just posted coverage.py 4.1b2, which no longer treats await or > yield-from as an exit from the function: > https://pypi.python.org/pypi/coverage/4.1b2 > > Any feedback appreciated :) > > --Ned. > > On Tuesday, January 12, 2016 at 3:20:08 AM UTC-5, Aymeric Augustin wrote: >> >> Hello Ned, >> >> On 12 janv. 2016, at 01:39, Ned Batchelder <[email protected]> wrote: >> >> > So we have a choice: Should coverage.py could insist on a branch to the >> > function exit? Pro: this could alert you to code you thought produced >> > values, but doesn't. Con: the places you know you aren't getting any >> > values, you'll have to use a pragma comment to shut up coverage.py. >> >> >> For developers who are only using `yield from` in the context of asyncio, >> this question is equivalent to: “should coverage.py mark a branch as not >> covered if a function never returns a result?”. The answer to that is “no”. >> >> For developers who are using `yield from` to simplify passing values from >> iterators across function call chains, there’s a good chance that something >> at one end of the chain will have an uncovered branch if no value is >> yielded. >> >> As a consequence, I believe the practical policy for coverage.py is to >> ignore the function exit branch in `yield from`. >> >> If you wanted to be really smart, you could try to tell apart `yield from >> generator` from `yield from coroutine`. As of Python 3.5, you could look at >> the CO_COROUTINE flag >> (https://www.python.org/dev/peps/pep-0492/#coroutine-objects). >> Unfortunately, it looks like this doesn't works for pre-3.5 coroutines >> decorated with @asyncio.coroutine — which is the only option for asyncio >> libraries that wish to support Python 3.4 and 3.3. >> >> -- >> Aymeric. >> > -- Thanks, Andrew Svetlov
