Interesting, care to explain then why Python supported threading since Python2? [1]
> Once again, if you are using python as a scripting language
> If that's true, then you shouldn't use python.
Once again, I don't. I use it as an orchestration language calling other code, and there is no good reason why the orchestration language should have an arbitrary bottleneck.
Yes, the hot code isn't written in Python. That doesn't matter to this discussion.
> In the "web application" example you are using, the norm is already to have many processes to handle incoming connections.
Outside of the python world, it absolutely isn't. I also have numerous Go based webservices, and they don't have to jump through ICP hoops to facilitate communications between workers and services.
It can't for the same reason python can't - every part was designed without it in mind.
> Python already does support it
The language runtime might have it in a branch, but the vast majority of C code it is based on, and the scripts themselves assume otherwise.
> fast single core machines
Once again, if you are using python as a scripting language, with C libraries, and spawning processes, you are already utilizing multiple cores without any adjustment on your part.
> CPU bound workloads become ever more important.
If that's true, then you shouldn't use python. It's about 100x slower than C. How much performance can you squeeze out of dividing work into cooperating threads, that can't be easily achieved by having multiple processes.
In the "web application" example you are using, the norm is already to have many processes to handle incoming connections.