2018: Python engineers have heard about concurrency :)
So if my next post about some lesser known part of the standard library (or whatever I want to talk about) is about a string method are you going to start your comment with "2018: Python engineers have heard about strings" ?
AFAIU, this executors were added in 3.2,
If you re-read the intro you'll notice I said the code works from Python 3.2 onwards, I'm well aware of that.
and they are unfortunately not a solution for the real life
So not a solution in real life that people (and me) have been using the underlying APIs these executor use for years in production.
Like ruby, python is stuck to be single-threaded not because there are no system thread/processes wrappers existing in the standard library, but because neither threads nor processes are robust enough to deal with real tasks usually requiring some action upon completion.
So, now you're saying that everyone that has ruby and python code in production using multiple threads or processes and doing fine doesn't exist because you decided threads and processes are not robust enough to deal with "real tasks"?
To deal with concurrency, the virtual machine is unfortunately required, and there are Java, Erlang and to some extent Golang to deal with the issue.
Please tell me in which part of my post I made a comparison with other languages. The whole post is about talking about a functionality that has been in the standard library for years and some people might not know about.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So if my next post about some lesser known part of the standard library (or whatever I want to talk about) is about a string method are you going to start your comment with "2018: Python engineers have heard about strings" ?
If you re-read the intro you'll notice I said the code works from Python 3.2 onwards, I'm well aware of that.
So not a solution in real life that people (and me) have been using the underlying APIs these executor use for years in production.
So, now you're saying that everyone that has ruby and python code in production using multiple threads or processes and doing fine doesn't exist because you decided threads and processes are not robust enough to deal with "real tasks"?
Please tell me in which part of my post I made a comparison with other languages. The whole post is about talking about a functionality that has been in the standard library for years and some people might not know about.