Proposal and sample implementation to address https://bugs.python.org/issue40320 and extend behavior a bit to get parity with what's available in synchronous code.

Makes three public API changes

1. Adds a context keyword parameter to the asyncio.Task constructor. When given this will be the contextvars.Context the task will be run in. When not specified the existing default of copying the callers context will still be used.
2. Updates asyncio.run to pass additional keyword arguments to the task constructor. This isn't really necessary but seemed like a nice (and it also seemed like it would be nice if you could specify the name of the task created by asyncio.run).
3. Created coroutine asyncio.run_in_context that functions in an analagous manner to contextvars.Context.run. It will manage swapping out the coroutine associated with the task while the passed coroutine is executing within the task.

asyncio.run_in_context is implemented by assing an additional private method Task._set_context that can change the context associated with a task (although a yield out of the task step function is required before the new context is active).

This is all to better support contextvars in an asyncio context. Without this support it was impossible to run async code in a different context without creating a new task. It was also impossible to create a task using any context other than a copy of the calling context (i.e. the context used was always a copy).

Example Usage

import asyncio
import contextvars

var = contextvars.ContextVar("var", default=123)

async def foo():
  val = var.get()
  var.set(val + 1)
  return val

async def main():
  assert await foo() == 123
  assert await asyncio.run_in_context(contextvars.copy_context(), foo()) == 124
  assert var.get() == 124

var.set(-1)
ctx = contextvars.Context()
asyncio.run(main(), name='main', context=ctx)

https://bugs.python.org/issue40320