On Tue, Apr 21, 2020 at 7:33 AM Victor Stinner <vstinner@python.org> wrote:
IMHO it's worth it to explore the subinterpreters approach. I don't think that it's going to be a major maintenance burden: the code is already written and tests. The PEP is only about adding a public Python API.
While this PEP may not create a maintenance burden for CPython, it does have the effect of raising the complexity bar for an alternative Python implementation.
Even today, asyncio didn't replace threads, multiprocessing, concurrent.futures, etc. There are even competitor projects like Twisted, trio and curio! (Also eventlet and gevent based on greenlet which is a different approach). I only started to see very recently project like httpx which supports both blocking and asynchronous API.
Because asyncio had been implemented as a library, the up-take of asyncio could have been lower because the demand was fulfilled, at least in part, by those third-party libraries? A thought that may have already been mentioned elsewhere: perhaps the PEP could be more made more acceptable by de-scoping it to expose a minimal set of C-API hooks to enable third-party libraries for the sub-interpreter feature rather than providing that feature in the standard library?