Problem with futures in 3.6.0b2 when "coverage" is enabled

[ronf]

I recently installed Python 3.6.0b2 and I've run into a problem with the handling of result values in asyncio Futures. This only seems to be triggered when I run with "coverage" enabled, but the problem appears to be specific to changes in asyncio between 3.6.0b1 and 3.6.0b2. Here's a small test program which reproduces the issue:

import asyncio

@asyncio.coroutine
def coro(fut):
    fut.set_result((1, 2, 3))

@asyncio.coroutine
def test():
    fut = asyncio.Future()

    asyncio.ensure_future(coro(fut))

    print((yield from fut))

asyncio.get_event_loop().run_until_complete(test())

When I run this as "python3.6 test.py", I get the proper output of (1, 2, 3). Similarly, when I run it with older version of Python with coverage enabled, like "python3.5 -m coverage run test.py", I get the same result. However, when I run "python3.6 -m coverage run test.py", the return value changes to just 1 (the first value in the tuple), discarding the rest.

I haven't tracked down the specific change in asyncio which is causing this, but reverting just the asyncio Python components back to 3.5 (which still running the 3.6 interpreter and rest of the 3.6 library) was enough to fix the problem. I think this will probably be the case if I go back to the 3.6.0b1 version of the asyncio module as well as I had no problems with that, but I haven't had a chance to revert back to that yet.

[ronf]

Just tried replacing the asyncio module with the version from 3.6.0b1, and confirmed that the problem was definitely introduced between 3.6.0b1 and 3.6.0b2. I'll try to narrow it down further when I get some time later this week.

[methane]

It may be http://bugs.python.org/issue28492 Removing _future extension module may solve it.

[1st1]

This problem is exactly the one that http://bugs.python.org/issue28492 fixed. I'll close this issue, @ronf thanks for reporting this and feel free to reopen.

[ronf]

Thanks - that does look like it might be it, and disabling lib/python3.6/lib-dynload/_futures.cpython-36m-darwin.so does appear to work around the issue for now!