> Within the context of a general purpose VM which was never built to support multithreading (CPython), How do you figure that? Even python2 already supported

> Within the context of a general purpose VM which was never built to support multithreading (CPython), How do you figure that? Even python2 already supported the usage of OS threads [1]. > 30+ years' worth of 3rd-party packages and libraries which were never built with multithreading in-mind Many of these packages also don't use other forms of concurrency, but are simply encapsulated functionality that runs in a single thread. Meaning, they will not be bothered by the change. Besides, as I have mentioned elsewhere, library maintainers always need to keep up with the development of the underlying language as well as usage patterns of the community, or their libraries become obsolete. That is true no matter what programming language we talk about. > If you need hardcore, ultra efficient and parallelized workflows - Python is just the wrong tool for the job period Python is already used as an orchestration language for huge numerical workloads, be it data science or machine learning. It is simple, intuitive and has by far the largest library support of any contemporary language. There is simply no good argument, why the language that we entrust to orchestrate this scale of computing power, shouldn't itself be as efficient as possible for a dynamically typed script-language. That this is absolutely possible, is demonstrated by languages like Julia. The fact that Python will never be as fast as Go, Rust or C++, doesn't change that. > Those people want to get shit done quickly - and mutexes, sempahores, events, threads, synchronization primitives, atomics, etc - will do nothing but make their lives a misery, and drive them away. Those people will for the most not even realize that the GIL is gone. If they write... - single threaded synchronous code - asyncio based code - multiprocessing code ...the change doesn't matter to them. The hobbyists small webserver, or the medium companies Flask-based webapp will still run as before. And if they write threading code, and do so correctly, then it is very likely the only change they will see, is that suddenly their application runs faster under high load. The removal of the GIL neither takes away existing capabilities from Python, nor does it force everyone to write threading code. > and you're not really responding which makes me feel like we're not conversing here... That's because I have done so elsewhere in this thread already [2] [1]: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html [2]: https://news.ycombinator.com/item?id=36918250 https://news.ycombinator.com/item?id=36918250