On Mon, Jun 21, 2021 at 7:20 PM Mark Gordon <[email protected]> wrote:
> > Yeah, it would indeed inherit the copy. We could, theoretically, make > > asyncio.Task accept context objects and not copy them, but what would > that > > give us? > > My main thinking was to just be similar to the closest synchronous analog > I'm aware of, contextvars.Context.run. I would think an explanation of why > the Context object API exists as it does, letting you manipulate and run in > contexts directly, would equally motivate the async analogs. Maybe the > exception would be if this API exists purely just to support async tasks > (then maybe it should be private?). > > At any rate, the issue attached to the pull requests gives one example of > seeking to do asyncio tests with providing fixture data through an existing > context object. I could also imagine a use case of wanting to track the > number of database requests made within a logical request that may span > multiple tasks. Having the subtasks inherit the same context could help > with this. > To track things like database requests just put a mutable object in the context somewhere at the top level, referenced by a well-known contextvar in your code. That single object will be part of all contexts derived from the top one throughout the application lifecycle. > > *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 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. > > > I guess we can add a keyword argument to asyncio.create_task() for that. > It > > is an open question if the task factory would just use the passed context > > object or would copy it first. I'm leaning towards the latter. > > My vote would be for not a copy as mentioned above. > > Having a asyncio.run_in_context(context, coro()) API is more important as > this feature is currently completely missing. So happy to table this if we > can't decide on if/what semantics this task kwarg API change should have. > Is asyncio.run_in_context() a version of asyncio.run() or a shortcut for Context.run(asyncio.create_task, coro)? Yury
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/CXQAKE65TBOJZGFGEAY5EKIEQ2WRSG6S/ Code of Conduct: http://python.org/psf/codeofconduct/
