Just found this thread as I was about to submit an issue about this. I would agree with Andrew that 4.1b2 looks right to me.
Thanks a lot. Samuel On Sunday, 24 January 2016 12:08:00 UTC, Andrew Svetlov wrote: > > 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] > <javascript:>> 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 >
