On Wed, Aug 30, 2017 at 1:39 PM, Kevin Conway <kevinjacobconway at gmail.com> wrote: >> 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 To work with coroutines we have asyncio/twisted or other frameworks. They create async tasks and manage them. Generators, OTOH, don't have a framework that runs them, they are managed by the Python interpreter. So its not possible to implement a *complete context solution* that equally supports generators and coroutines outside of the interpreter. Another problem, is that every framework has its own local context solution. Twisted has one, gevent has another. But libraries like numpy and decimal can't use them to store their local context data, because they are non-standard. That's why we need to solve this problem once in Python directly. 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