3 ms·

I'm so conflicted. ~40 of the programs I am responsible for are single threaded. They were relatively quick to develop and were made by Electrical Engineers ra

I'm so conflicted. ~40 of the programs I am responsible for are single threaded. They were relatively quick to develop and were made by Electrical Engineers rather than career/degreed programmers. 2 programs use multithreading, I had to do that. The learning curve was not a huge deal, but the development time adds at least hours. In my case days(due to testing). I imagine its too hard to have an optional flag at the start of each program that can let the user decide?

birdyrooster 3y ago
The problem is that Python types are not thread safe so you have to jump through more hoops to have safe parallelization in Python. These changes would make it so that writing multithreaded code will be much easier it seems like.
maleldil 3y ago
> I imagine its too hard to have an optional flag at the start of each program that can let the user decide? Adding nogil would mean deep changes to the interpreter. I imagine maintaining both versions would be almost like forking the project.
coldtea 3y ago
>but the development time adds at least hours So? some "hours of development time" is nothing.
- sfink 3y ago
  True, and as you get better at it, those hours will be fewer. The weeks of debugging never go away, though. (Or at least, not as long as you're using shared state, but that's really the only thing under consideration here.)
- hospitalJail 3y ago
  I'm mostly with you. I think this probably affects part time/newbie programmers more. A few hours of dev time is 1 or 2 nights of work.
dragonwriter 3y ago
> I imagine its too hard to have an optional flag at the start of each program that can let the user decide? The actual next-step proposal toward no-gil is GIL as a build-time flag (which isn’t quite the same as a runtime flag, but not too far off, either.) https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/
nunuvit 3y ago
It's not like CPython is depriving anyone of GIL-free Python. IronPython and Jython are GIL-free. You can have it yesterday. CPython maintains Python's original purpose as a glue language. You know how much worse CPython would be for that use-case without the GIL. GVR has said he'll support removing the GIL as long as there's no performance hit. Otherwise, it's simply asking for a fundamental change of direction and too much sacrifice from everyone who needs CPython specifically, just to improve the productivity of people who could use a different Python.

birdyrooster 3y ago

The problem is that Python types are not thread safe so you have to jump through more hoops to have safe parallelization in Python. These changes would make it so that writing multithreaded code will be much easier it seems like.

maleldil 3y ago

> I imagine its too hard to have an optional flag at the start of each program that can let the user decide? Adding nogil would mean deep changes to the interpreter. I imagine maintaining both versions would be almost like forking the project.

coldtea 3y ago

>but the development time adds at least hours So? some "hours of development time" is nothing.

sfink 3y ago
True, and as you get better at it, those hours will be fewer. The weeks of debugging never go away, though. (Or at least, not as long as you're using shared state, but that's really the only thing under consideration here.)
hospitalJail 3y ago
I'm mostly with you. I think this probably affects part time/newbie programmers more. A few hours of dev time is 1 or 2 nights of work.

dragonwriter 3y ago

> I imagine its too hard to have an optional flag at the start of each program that can let the user decide? The actual next-step proposal toward no-gil is GIL as a build-time flag (which isn’t quite the same as a runtime flag, but not too far off, either.) https://peps.python.org/pep-0703/ https://peps.python.org/pep-0703/

nunuvit 3y ago

It's not like CPython is depriving anyone of GIL-free Python. IronPython and Jython are GIL-free. You can have it yesterday. CPython maintains Python's original purpose as a glue language. You know how much worse CPython would be for that use-case without the GIL. GVR has said he'll support removing the GIL as long as there's no performance hit. Otherwise, it's simply asking for a fundamental change of direction and too much sacrifice from everyone who needs CPython specifically, just to improve the productivity of people who could use a different Python.