> *Ultimately, contextvars enable implicit flow
> of information from outer code to nested code and not vice versa. *
> Just to clarify, are you stating an established position of the python
> community or is this your personal view of how context vars should be used?
> I'm stating this as the original contextvars PEP author and implementer. I
Oh very cool, thanks for taking the time to look at this.
don't see how the reverse flow is possible to implement within all
restrictions of the design space. To propagate information from nested
calls to outer calls just use mutable objects, as I outlined above.
> Additionally (obviously) it will also be running in a separate task.
> There's no way around that, unfortunately. Even if we add some kind of
> helper to run coroutines in a context, there still we be a task object
> that
> iterates the coroutine.
> I was just pointing out that the stated work-around requires creating an
> additional task to run the called coroutine rather than running directly in
> the calling task.
> Yes, and I'm saying that running a coroutine "directly on the stack" within
some context is not technically possible, without wrapping it into a Task.
Is there something wrong with the solution of changing the context associated with a task before execution, yielding, run the coroutine, then swap it back and yield again when the coroutine exits? This is the hacky solution that appears to work for me on python 3.8 if I force use of _PyTask (and the linked PR extends this idea to work for the CTask implementation).