5 ms·

The problem is, code that uses on a lot of 3rd party libraries that throws the ON-switch for nogil, will suddenly depend on all these libraries maintainers havi

The problem is, code that uses on a lot of 3rd party libraries that throws the ON-switch for nogil, will suddenly depend on all these libraries maintainers having worried about this.

seunosewa 3y ago
We can set it up such that if a module imports modules that don't support nogil, nogil will be automatically disabled for them too. So, library designers will be under pressure to update their libraries to enable support. We could also have code tools that detect patterns that aren't GIL safe and throw out loud warnings
- zarzavat 3y ago
  Why should library authors be put under pressure because someone else chose the wrong tool for the job, and is now trying to push that externality on to the community? Python is a single-threaded language. That’s part of its DNA. The community has already been through one traumatic transition in recent history and the appetite for another one is low. Library authors should not update their libraries to support multithreading, rather the people who want that should be forced to rewrite their code in a language that is more suitable for the problem they want to solve.
  - rolisz 3y ago
    I disagree that single threadedness is in its DNA. It's an implementation detail of CPython. There are other implementations which don't have a GIL even today. Would removing the GIL be a big change for CPython? Yes. But IMO it's worth it
  - hughesjj 3y ago
    > Python is a single-threaded language. That’s part of its DNA. Boooo. Maybe if all you do is ops scripts, but for those of us in data science this couldn't be further from the truth imo. I'm not saying the syntax is easy for asyncio, or anywhere near as nice as golang or even kotlin is for concurrency, but it's definitely workable in a concurrent environment.
  - usrbinbash 3y ago
    > Python is a single-threaded language. That’s part of its DNA. If the changes proposed in this PEP go through, that will no longer be the case. So library authors pretty much will have to either update, or see their modules wither the same way they would if they weren't updated as new Python 3.x versions come along. > rather the people who want that should be forced to rewrite their code in a language that is more suitable for the problem they want to solve The vast majority of the Python developer community WANT Python to support true multithreading and being able to solve these problems. We expend inordinate amounts of time and skill trying to make Python work around the GIL, eg. by utilizing multiprocessing. We want Python to stay relevant long-term. In an age of abundant multi-core platforms, and workloads that can utilize them, the GIL is a major obstacle to that desire.
  - akdor1154 3y ago
    > Python is a single-threaded language Err what? import threading from concurrent.futures import ThreadPoolExecutor
  - oblio 3y ago
    This is wrong, that ship sailed 10+ years ago. Python is used for almost everything, better get used to it. This kind of garbage logic lead to the horrible Ruby/Python/Javascript with C extensions split that makes their ecosystems very brittle, versus Java/C# where it is expected that things are fast enough without C and package management is much easier.
    - cwalv 3y ago
      It's true that python is used for "almost everything", but it's only true because it plays nicely with C. I understand the desire/demand for general purpose tools. The thing is, there are always tradeoffs. Acknowledging the tradeoffs and designing more specialized tools that work well together isn't necessarily garbage logic.
      - oblio 3y ago
        Python is no longer specialized. I mean, it's specialized for: * data science * AI/ML * webdev * DevOps tools * an embedded extension language for 100000 programs ... The sooner core Python devs accept this, the sooner the right thing can be done. Python is not AWK.
  - dragonwriter 3y ago
    > Python is a single-threaded language. Its literally not, though, even with the GIL.

The problem is, code that uses on a lot of 3rd party libraries that throws the ON-switch for nogil, will suddenly depend on all these libraries maintainers having worried about this.

seunosewa 3y ago

We can set it up such that if a module imports modules that don't support nogil, nogil will be automatically disabled for them too. So, library designers will be under pressure to update their libraries to enable support. We could also have code tools that detect patterns that aren't GIL safe and throw out loud warnings

zarzavat 3y ago
Why should library authors be put under pressure because someone else chose the wrong tool for the job, and is now trying to push that externality on to the community? Python is a single-threaded language. That’s part of its DNA. The community has already been through one traumatic transition in recent history and the appetite for another one is low. Library authors should not update their libraries to support multithreading, rather the people who want that should be forced to rewrite their code in a language that is more suitable for the problem they want to solve.
- rolisz 3y ago
  I disagree that single threadedness is in its DNA. It's an implementation detail of CPython. There are other implementations which don't have a GIL even today. Would removing the GIL be a big change for CPython? Yes. But IMO it's worth it
- hughesjj 3y ago
  > Python is a single-threaded language. That’s part of its DNA. Boooo. Maybe if all you do is ops scripts, but for those of us in data science this couldn't be further from the truth imo. I'm not saying the syntax is easy for asyncio, or anywhere near as nice as golang or even kotlin is for concurrency, but it's definitely workable in a concurrent environment.
- usrbinbash 3y ago
  > Python is a single-threaded language. That’s part of its DNA. If the changes proposed in this PEP go through, that will no longer be the case. So library authors pretty much will have to either update, or see their modules wither the same way they would if they weren't updated as new Python 3.x versions come along. > rather the people who want that should be forced to rewrite their code in a language that is more suitable for the problem they want to solve The vast majority of the Python developer community WANT Python to support true multithreading and being able to solve these problems. We expend inordinate amounts of time and skill trying to make Python work around the GIL, eg. by utilizing multiprocessing. We want Python to stay relevant long-term. In an age of abundant multi-core platforms, and workloads that can utilize them, the GIL is a major obstacle to that desire.
- akdor1154 3y ago
  > Python is a single-threaded language Err what? import threading from concurrent.futures import ThreadPoolExecutor
- oblio 3y ago
  This is wrong, that ship sailed 10+ years ago. Python is used for almost everything, better get used to it. This kind of garbage logic lead to the horrible Ruby/Python/Javascript with C extensions split that makes their ecosystems very brittle, versus Java/C# where it is expected that things are fast enough without C and package management is much easier.
  - cwalv 3y ago
    It's true that python is used for "almost everything", but it's only true because it plays nicely with C. I understand the desire/demand for general purpose tools. The thing is, there are always tradeoffs. Acknowledging the tradeoffs and designing more specialized tools that work well together isn't necessarily garbage logic.
    - oblio 3y ago
      Python is no longer specialized. I mean, it's specialized for: * data science * AI/ML * webdev * DevOps tools * an embedded extension language for 100000 programs ... The sooner core Python devs accept this, the sooner the right thing can be done. Python is not AWK.
- dragonwriter 3y ago
  > Python is a single-threaded language. Its literally not, though, even with the GIL.