When the concurrent Future wrapped by asyncio.wrap_future has set_result or set_exception called multiple times, I get the following traceback:Traceback (most recent call last):  File "/usr/local/lib/python3.6/asyncio/events.py", line 145, in _run    self._callback(*self._args)  File "/usr/local/lib/python3.6/asyncio/futures.py", line 399, in _set_state    _copy_future_state(other, future)  File "/usr/local/lib/python3.6/asyncio/futures.py", line 369, in _copy_future_state    assert not dest.done()AssertionErrorMinimal reproducible example:import asyncioimport concurrent.futuresf = concurrent.futures.Future()async_f = asyncio.wrap_future(f)f.set_result(1)f.set_result(1)loop = asyncio.get_event_loop()loop.run_until_complete(async_f)The documentation says that set_result and set_exception are only meant for Executors, so, arguably using them outside of that context would fall into undocumented behavior rather than a bug. But it still seems like it should be the second set_result that raises something like InvalidStateError. Alternatively, this can be avoided if _copy_future_state checks for done in addition to cancellation. What should happen here?

May also be worth pointing out that even in the case of only calling set_result once, _done_callbacks still has _chain_future in it:import asyncioimport concurrent.futuresf = concurrent.futures.Future()async_f = asyncio.wrap_future(f)f.set_result(1)loop = asyncio.get_event_loop()print(loop.run_until_complete(async_f))print(f._done_callbacks)>>> 1>>> [<function _chain_future.<locals>._call_set_state at 0x7f1687f3c620>]Should that be cleared by that point?

Raising `InvalidStateError` sounds perfect.Would you make a pull request?

New changeset0a28c0d12ee7201de039ced4d815f57f1f8fd48c by Andrew Svetlov (jhaydaman) in branch 'master':bpo-33238: Add InvalidStateError to concurrent.futures. (GH-7056)https://github.com/python/cpython/commit/0a28c0d12ee7201de039ced4d815f57f1f8fd48c