On Tue, Aug 29, 2017 at 4:33 PM, Antoine Pitrou <anto...@python.org> wrote: > > Le 29/08/2017 à 22:20, Yury Selivanov a écrit : >> >> 2) >> >> gvar = new_context_var() >> var = new_context_var() >> >> async def bar(): >> # EC = [current_thread_LC_copy, Task_foo_LC_copy, Task_wait_for_LC] > > Ah, thanks!... That explains things, though I don't expect most users > to spontaneously infer this and its consequences from the fact that they > used "wait_for()".
Yeah, we use "# EC=" comments in the PEP to explain how EC is implemented for generators (in the Detailed Specification section), and will now do the same for coroutines (in the next update). > > This seems actually even more problematic, because if bar() can mutate > Task_wait_for_LC, it may unwillingly affect wait_for() (assuming the > wait_for() implementation may some day use EC for whatever purpose, e.g. > logging). In general the patter is to wrap the passed coroutine into a Task and then attach some callbacks to it (or wrap the coroutine into another coroutine). So while I understand the concern, I can't immediately come up with a realistic example... > > It seems framework code like wait_for() should have a way to override > the default behaviour and remove their own LC's from "child" coroutines' > lookup chaines. Perhaps the PEP already allows for his? Yes, the PEP provides enough APIs to implement any semantics we want. We might want to add "execution_context" kwarg to "asyncio.create_task" to make this customization of EC easy for Tasks. Yury _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
