4 ms·

It's good if there's a benefit for everyone, like python 3 fixing the terrible Unicode story. It's not clear non-GIL will even be a net performance improvement

It's good if there's a benefit for everyone, like python 3 fixing the terrible Unicode story. It's not clear non-GIL will even be a net performance improvement for most people--you are effectively moving syncronization from the core runtime to each and every library and program at the edge. Writing safe code at that level doesn't come for free, your basic program will be slower (and likely buggier) if every call into a library is now doing its own little bespoke GIL instead of relying on python's global one like now.

wokwokwok 3y ago
I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions. Pypi has what, 500k projects on it? Many abandoned. Whom exactly is going to update those? Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it? Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode? Like, sure… it’s a good change for many people… once all the hard work is done by the community. Does that remind you of anything? Mmm.
- qbasic_forever 3y ago
  Yep I fully agree. It's going to ultimately mean 99% of people end up running in old GIL mode with deterministic behavior. Companies will get burned and have to have policies that absolutely under no circumstances will the GIL be disabled in their codebase. A very small handful of highly skilled and funded teams, probably at big companies only, will have the time and tenacity to make their code AND all their dependencies work in a multithreaded environment without the GIL.
  - 8n4vidtmkvmk 3y ago
    I work at a big company. We had probably millions of lines of Python. We migrated to c++ instead of to Python 3.
    - abdulhaq 3y ago
      I'm really struggling to think of a scenario where that makes sense
      - 8n4vidtmkvmk 3y ago
        I'm not convinced it's was the right choice either, but I'm not keen on Python, and not sold on Rust. Maybe Zig? I don't know. I personally like Typescript but even I will admit I'm not sure it's the best choice for a large, server-centric company.
- miraculixx 3y ago
  At the end of the day,this is the very point the SC and core devs are ignoring in their decision. They do recognize the impact on the ecosystem will be huge, they recognize there will be at least 5 years of parallel gil/nogil versions(*), and they say they don't want a 2-3 story all over again. Yet they have decided against their own best advise (to avoid such a situation). I find it utterly confusing. (*) not just one parallel version, there will be 2 for every release following the introduction. In reality organisations will have to maintain 4-6 different baselines of Python releases along with a matching (and likely differing) set of libraries. I don't mean to fearmonger, I just happen to maintain such environements and I know the effort that goes into this first hand.
  - geekraver 3y ago
    They were put in an untenable situation, IMO. If they said no, there would be howls of protest, and a possible schism in the community, and the next SC elections could be an ugly competition between pro- and anti-GIL advocates. A "yes, but..." approach was about the only option.
- usrbinbash 3y ago
  First of all, these changes are not being introduced because of a committee. They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python developer community for ages. > “but now I have to rewrite my library because some people might use it in non-GIL mode”. Yes, if library maintainers want their library to remain relevant, they will need to accomodate what the languages developer community uses. This is true for all languages. If they don't want to, that's okay, the community will come up with new libraries. > the committee making these decisions gives zero ducks about the impact this will have If they were giving zero ducks, they wouldn't make it backwards compatible, nor would there be a command line option to control the behavior. >Pypi has what, 500k projects on it? Many abandoned. > >Whom exactly is going to update those? Languages that base decisions on the update behavior, or lack thereof, of library maintainers, effectively freeze themselves. And why exactly is the update behavior of abandoned packages a problem? They are abandoned anyway. > Like, sure… it’s a good change for many people… once all the hard work is done by the community. The people who want to get rid of the GIL are part of the Python development community. Many of them are library developers themselves.
  - miraculixx 3y ago
    > They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading. There is a very small number of use cases that will benefit from free threading.
    - usrbinbash 3y ago
      > Where is this demand exactly? The motivation summary of PEP-703 contains some material on this: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation Further discussions going back years can be found with a brief search. This discussion is almost as old as Python3. > due to a lack of awareness of available (& often better) alternatives to threading. Such as? There are exactly 2: asyncio, which is useless for CPU/GPU bound workloads, and multiprocessing with all the pain of relying on expensive spawns, expensive and limited IPC and the joy of having to orchestrate across process boundaries. Guess what the most common advice is for dealing with CPU bound parallelisation problems in Python? "Use another language". Guess what all the languages recommended (C, C++, Rust, Go, Java) have in common? They have thread-based parallelism. > There is a very small number of use cases that will benefit from free threading. Basically any workload that is CPU bound, which in the day and age of giant data aggragation and running huge ML models at scale is more important than every before, is a use case for this.
- Dylan16807 3y ago
  > I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. 1. But they don't "have to". 2. Even if they did, why would downvoting be "disingenuous"?
- samus 3y ago
  > Pypi has what, 500k projects on it? Many abandoned. Most of them don't contain C extensions. > Whom exactly is going to update those? Its developers of course. Many are presumably watching PEP-703, others will require lobbying by their users. But there is no rush to do so because... > Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it? > Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode? ... the interpreter will indeed fall back to enable the GIL if an extension is loaded that doesn't declare support of the no-GIL mode. Additionally, some extensions are actually safe to use without GIL as long as their Python APIs prevent concurrent access to them and thus act like the GIL themselves. In these cases, the interpreter can be forced to run without the GIL. Isolating the C extension to another process is another possibility to reduce the impact on applications where all others can already run without the GIL. Actually, multiprocessing is already a common approach in the Python ecosystem for concurrent and parallel processing.
- pritambaral 3y ago
  > Pypi has what, 500k projects on it? Many abandoned. > Whom exactly is going to update those? > once all the hard work is done by the community. If I want to use Python with parallel threads in the app I'm building, I don't need to wait for every last one of those 500k packages. I can wait for only the packages I'm using, or risk it and force Python to run in nogil mode anyway. It's my choice. > Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it? As other comments say in this thread: yes. > Does that remind you of anything? > Mmm. 2-to-3 burned you. We get it. You might be getting flashbacks to that nightmare. That is understandable. But you need to look beyond a surface level similarity — "That was a transition. This is a transition. They're identical!" — and at the actual transition itself. The problems of 2-to-3 aren't present here. The user is not forced to choose between two incompatible options. Library authors aren't forced to migrate their code forward. Users and library authors do not need to collectively choose one version over another. The newer version remains compatible with older code. The sky is not falling.
imtringued 3y ago
> every call into a library is now doing its own little bespoke GIL instead of relying on python's global one like now. Is this some kind of joke? Do we live in clown world now? You do realize that a lock is a trivial primitive in multi threading? The concept of a "little bespoke GIL" is ridiculous. A lock is a lock. Sure, an extension could just put a global lock on every extension call and then you do end up with an extension wide lock but every other extension remains unaffected. There is no intelligence or genius behind putting a global lock in the interpreter that somehow gets ruined by putting the lock in the extension. In fact, GIL is the dumbest decision you could make and everything from that point on can only get better, not worse.

wokwokwok 3y ago

I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. That’s not whining; it’s just an observation that the committee making these decisions gives zero ducks about the impact this will have for anyone other than the handful of vested parties involved in making the decisions. Pypi has what, 500k projects on it? Many abandoned. Whom exactly is going to update those? Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it? Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode? Like, sure… it’s a good change for many people… once all the hard work is done by the community. Does that remind you of anything? Mmm.

qbasic_forever 3y ago
Yep I fully agree. It's going to ultimately mean 99% of people end up running in old GIL mode with deterministic behavior. Companies will get burned and have to have policies that absolutely under no circumstances will the GIL be disabled in their codebase. A very small handful of highly skilled and funded teams, probably at big companies only, will have the time and tenacity to make their code AND all their dependencies work in a multithreaded environment without the GIL.
- 8n4vidtmkvmk 3y ago
  I work at a big company. We had probably millions of lines of Python. We migrated to c++ instead of to Python 3.
  - abdulhaq 3y ago
    I'm really struggling to think of a scenario where that makes sense
    - 8n4vidtmkvmk 3y ago
      I'm not convinced it's was the right choice either, but I'm not keen on Python, and not sold on Rust. Maybe Zig? I don't know. I personally like Typescript but even I will admit I'm not sure it's the best choice for a large, server-centric company.
miraculixx 3y ago
At the end of the day,this is the very point the SC and core devs are ignoring in their decision. They do recognize the impact on the ecosystem will be huge, they recognize there will be at least 5 years of parallel gil/nogil versions(*), and they say they don't want a 2-3 story all over again. Yet they have decided against their own best advise (to avoid such a situation). I find it utterly confusing. (*) not just one parallel version, there will be 2 for every release following the introduction. In reality organisations will have to maintain 4-6 different baselines of Python releases along with a matching (and likely differing) set of libraries. I don't mean to fearmonger, I just happen to maintain such environements and I know the effort that goes into this first hand.
- geekraver 3y ago
  They were put in an untenable situation, IMO. If they said no, there would be howls of protest, and a possible schism in the community, and the next SC elections could be an ugly competition between pro- and anti-GIL advocates. A "yes, but..." approach was about the only option.
usrbinbash 3y ago
First of all, these changes are not being introduced because of a committee. They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python developer community for ages. > “but now I have to rewrite my library because some people might use it in non-GIL mode”. Yes, if library maintainers want their library to remain relevant, they will need to accomodate what the languages developer community uses. This is true for all languages. If they don't want to, that's okay, the community will come up with new libraries. > the committee making these decisions gives zero ducks about the impact this will have If they were giving zero ducks, they wouldn't make it backwards compatible, nor would there be a command line option to control the behavior. >Pypi has what, 500k projects on it? Many abandoned. > >Whom exactly is going to update those? Languages that base decisions on the update behavior, or lack thereof, of library maintainers, effectively freeze themselves. And why exactly is the update behavior of abandoned packages a problem? They are abandoned anyway. > Like, sure… it’s a good change for many people… once all the hard work is done by the community. The people who want to get rid of the GIL are part of the Python development community. Many of them are library developers themselves.
- miraculixx 3y ago
  > They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading. There is a very small number of use cases that will benefit from free threading.
  - usrbinbash 3y ago
    > Where is this demand exactly? The motivation summary of PEP-703 contains some material on this: https://peps.python.org/pep-0703/#motivation https://peps.python.org/pep-0703/#motivation Further discussions going back years can be found with a brief search. This discussion is almost as old as Python3. > due to a lack of awareness of available (& often better) alternatives to threading. Such as? There are exactly 2: asyncio, which is useless for CPU/GPU bound workloads, and multiprocessing with all the pain of relying on expensive spawns, expensive and limited IPC and the joy of having to orchestrate across process boundaries. Guess what the most common advice is for dealing with CPU bound parallelisation problems in Python? "Use another language". Guess what all the languages recommended (C, C++, Rust, Go, Java) have in common? They have thread-based parallelism. > There is a very small number of use cases that will benefit from free threading. Basically any workload that is CPU bound, which in the day and age of giant data aggragation and running huge ML models at scale is more important than every before, is a use case for this.
Dylan16807 3y ago
> I’m not gonna argue that point; but it seems massively disingenuous to down vote someone who complains “but now I have to rewrite my library because some people might use it in non-GIL mode”. 1. But they don't "have to". 2. Even if they did, why would downvoting be "disingenuous"?
samus 3y ago
> Pypi has what, 500k projects on it? Many abandoned. Most of them don't contain C extensions. > Whom exactly is going to update those? Its developers of course. Many are presumably watching PEP-703, others will require lobbying by their users. But there is no rush to do so because... > Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it? > Or do we live in a future where any package, with any dependency may or may not have undefined behaviour in no-GIL mode? ... the interpreter will indeed fall back to enable the GIL if an extension is loaded that doesn't declare support of the no-GIL mode. Additionally, some extensions are actually safe to use without GIL as long as their Python APIs prevent concurrent access to them and thus act like the GIL themselves. In these cases, the interpreter can be forced to run without the GIL. Isolating the C extension to another process is another possibility to reduce the impact on applications where all others can already run without the GIL. Actually, multiprocessing is already a common approach in the Python ecosystem for concurrent and parallel processing.
pritambaral 3y ago
> Pypi has what, 500k projects on it? Many abandoned. > Whom exactly is going to update those? > once all the hard work is done by the community. If I want to use Python with parallel threads in the app I'm building, I don't need to wait for every last one of those 500k packages. I can wait for only the packages I'm using, or risk it and force Python to run in nogil mode anyway. It's my choice. > Or do packages get an automatic “doesn’t work with no-GIL” unless the author explicitly opts to enable it? As other comments say in this thread: yes. > Does that remind you of anything? > Mmm. 2-to-3 burned you. We get it. You might be getting flashbacks to that nightmare. That is understandable. But you need to look beyond a surface level similarity — "That was a transition. This is a transition. They're identical!" — and at the actual transition itself. The problems of 2-to-3 aren't present here. The user is not forced to choose between two incompatible options. Library authors aren't forced to migrate their code forward. Users and library authors do not need to collectively choose one version over another. The newer version remains compatible with older code. The sky is not falling.

imtringued 3y ago

> every call into a library is now doing its own little bespoke GIL instead of relying on python's global one like now. Is this some kind of joke? Do we live in clown world now? You do realize that a lock is a trivial primitive in multi threading? The concept of a "little bespoke GIL" is ridiculous. A lock is a lock. Sure, an extension could just put a global lock on every extension call and then you do end up with an extension wide lock but every other extension remains unaffected. There is no intelligence or genius behind putting a global lock in the interpreter that somehow gets ruined by putting the lock in the extension. In fact, GIL is the dumbest decision you could make and everything from that point on can only get better, not worse.