> Can Execution Context be implemented outside of CPython I know I'm well late to the game and a bit dense, but where in the pep is the justification for this assertion? I ask because we buy something to solve the same problem in Twisted some time ago: https://bitbucket.org/hipchat/txlocal . We were able to leverage generator/coroutine decorators to preserve state without modifying the runtime.
Given that this problem only exists in runtime that multiplex coroutines on a single thread and the fact that coroutine execution engines only exist in user space, why doesn't it make more sense to leave this to a library that engines like asyncio and Twisted are responsible for standardising on? On Wed, Aug 30, 2017, 09:40 Yury Selivanov <[email protected]> wrote: > On Wed, Aug 30, 2017 at 9:44 AM, Yury Selivanov <[email protected]> > wrote: > [..] > >> FYI, I've been sketching an alternative solution that addresses these > kinds > >> of things. I've been hesitant to post about it, partly because of the > >> PEP550-based workarounds that Nick, Nathaniel, Yury etc. have been > >> describing, and partly because that might be a major distraction from > other > >> useful discussions, especially because I wasn't completely sure yet > about > >> whether my approach has some fatal flaw compared to PEP 550 ;). > > > > We'll never know until you post it. Go ahead. > > The only alternative design that I considered for PEP 550 and > ultimately rejected was to have a the following thread-specific > mapping: > > { > var1: [stack of values for var1], > var2: [stack of values for var2] > } > > So the idea is that when we set a value for the variable in some > frame, we push it to its stack. When the frame is done, we pop it. > This is a classic approach (called Shallow Binding) to implement > dynamic scope. The fatal flow that made me to reject this approach > was the CM protocol (__enter__). Specifically, context managers need > to be able to control values in outer frames, and this is where this > approach becomes super messy. > > Yury > _______________________________________________ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/kevinjacobconway%40gmail.com >
_______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com