@kunalq suggested this on #34 and it seems like a good idea to catch little issues in tests.

I'm not sure how to do this, but it'd be really nice to have tests that the typing plugin for duet.sync works properly. This could avoid breakages like the one fixed by #36. I've looked around in the mypy docs for some tips about testing type annotations, but haven't found much, so we might have to roll our own scheme.

There seems to be an issue with repeated interrupts in the same task. I discovered this when trying to sleep in a loop, but doing two back-to-back sleeps also fails:

await duet.sleep(1)
await duet.sleep(1)

The first sleep succeeds, but the second sleep causes duet to block indefinitely. I haven't diagnosed the root cause here, but it is probably a confusion with edge- versus level-triggering of interrupts. Basically, we need to allow a given task to be interrupted more than once as long as interrupts are handled and don't cause the task to exit.

Currently when a task is cancelled we use concurrent.futures.CancelledError, which derives from Exception, rather than BaseException. The problem with this is that code that catches Exception will also capture CancelledError and may thus inadvertently swallow the cancellation. We might want to use an exception type that derives from BaseException instead, so that it will propagate by default unless the user does something to explicitly catch it.

It'd be very useful to have support for deadlines and timeouts in duet (deadlines are absolute points in time while timeouts are relative to now). In what follows, I will say "deadlines" to refer to both. Here's a sketch of how the API could work:

async with duet.deadline(time.time() + 1):
    await some_future
    # raises TimeoutError and cancels some_future if it does not complete in 1 sec

async with duet.timeout(1):
    await some_future
    # raises TimeoutError and cancels some_future if it does not complete in 1 sec

Deadlines are scoped, and any async tasks spawned within the scope or any subscopes will inherit the same deadline. For convenience, we will allow specifying a deadline or timeout directly on duet.new_scope via duet.new_scope(deadline=...) or duet.new_scope(timeout=...):

async with duet.new_scope(deadline=when) as scope:
    ...

# equivalent to:
async with duet.deadline(when):
    async with duet.new_scope() as scope:
        ...

Implementation of this would involve storing the current (optional) deadline somewhere and using it in Scheduler.tick to avoid blocking forever waiting for tasks to become ready (e.g. the Condition.wait call in ReadySet.get_all).

Publish a final version of duet-async 0.1.x that points to the new duet package instead.

See here.

We'd like to be able to use duet in python3.6 since it's still used by colab and internally at google (see quantumlib/Cirq#4009). Among other things, this will require adding back in support for AsyncContextManager and adding a 3.6-only dependency on contextvars. There may be some other changes required as well.