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.
