On Tue, Aug 29, 2017 at 4:33 PM, Antoine Pitrou <antoine at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4