3 ms·
Since a. this is functionally equivalent to coroutines implemented via library support through generators b. Python will never ever get rid of the GIL, i.e. w
by anon4 12y ago
Since
a. this is functionally equivalent to coroutines implemented via library support through generators
b. Python will never ever get rid of the GIL, i.e. won't have real parallelism (given that the JVM/CLR Python implementations are basically dead and PyPy is chasing the pype dream of STM, we're left with CPython the only actual implementation)
Is there any reason to add new syntax? Other than wishful thinking that one day someone will write a Python runtime with proper JIT and parallelism support?
- pmalynin 12y agoStackless Python
- ynik 12y agoasync/await is useful for more than just 'real parallelism': its main use is coordinating concurrency. The GIL isn't a problem when dealing with async IO or async calls into C libraries.
- gamesbrainiac 12y agoThere's already a good bit of work on getting rid of the GIL in pypy. pypy also has channels (borrowed from stackless).
- anonymoushn 12y agoThis is a control flow primitive. You wouldn't hold off on implementing "call/cc" or "function calls" or "loops" until after you have multiple threads running the interpreter, imo.