> 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 <yselivanov.ml@gmail.com> wrote:
On Wed, Aug 30, 2017 at 9:44 AM, Yury Selivanov <yselivanov.ml@gmail.com> 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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/kevinjacobconway%40gmail.com