On Tue, Apr 21, 2020 at 7:33 AM Victor Stinner <vstin...@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? _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KSRMK2OULUHM4KTKAFXWO6RFM2F2IWE6/ Code of Conduct: http://python.org/psf/codeofconduct/
