4 ms·

> There are no good answers afaik. I shall be more than happy to provide them: Supporting thread based parallelism is the norm among all mainstream PLs with t

> There are no good answers afaik. I shall be more than happy to provide them: Supporting thread based parallelism is the norm among all mainstream PLs with the one inglorious exception of JS, which doesn't because it simply can't. And Python already does support it, it simply is limited by a legacy design decision. That was okay in a bygone age when fast single core machines were still the norm, Python was primarily a scripting language for when bash wasn't enough, and most relevant webapps were IO bound. Today, there simply is no excuse any more. Python is the most ubiquitous language in the world, and running scaling web applications, is the lingua franca of ML, and orchestrates huge systems. Servers have hundreds of cores, and CPU bound workloads become ever more important. It's about time Python rids itself of that needless limitation.

commonlisp94 3y ago
> because it simply can't. 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.
- usrbinbash 3y ago
  > every part was designed without it in mind. 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. [1]: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html
csmpltn 3y ago
> "It's about time Python rids itself of that needless limitation." I want to correct one thing that I see plastered all over this thread. The GIL isn't a programming language construct. It's an implementation detail. The GIL isn't a "Python limitation" in any way, because it has nothing to do with Python. CPython (aka. Cython), probably the most popular and widely used VM for Python, was built around a GIL. There are other VMs out there that don't have a GIL (ie. Jython, IronPython) and can be used out of the box.
- usrbinbash 3y ago
  > It's an implementation detail. It's an implementation detail of CPython. Which is by far the most common Python interpreter. And it limits parallelisation via threads in Python, a language that otherwise natively supports threading. So yes, it IS a needless limitation.

commonlisp94 3y ago

> because it simply can't. 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.

usrbinbash 3y ago
> every part was designed without it in mind. 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. [1]: https://docs.python.org/2/library/threading.html https://docs.python.org/2/library/threading.html

csmpltn 3y ago

> "It's about time Python rids itself of that needless limitation." I want to correct one thing that I see plastered all over this thread. The GIL isn't a programming language construct. It's an implementation detail. The GIL isn't a "Python limitation" in any way, because it has nothing to do with Python. CPython (aka. Cython), probably the most popular and widely used VM for Python, was built around a GIL. There are other VMs out there that don't have a GIL (ie. Jython, IronPython) and can be used out of the box.

usrbinbash 3y ago
> It's an implementation detail. It's an implementation detail of CPython. Which is by far the most common Python interpreter. And it limits parallelisation via threads in Python, a language that otherwise natively supports threading. So yes, it IS a needless limitation.