(Posted for the whole Steering Council.) As we’ve announced before, the Steering Council has decided to accept PEP 703 (Making the Global Interpreter Lock Optional in CPython) . We want to make it clear why, and under what expectations we’re doing so. It is clear to the Steering Council that theoretically, a no-GIL (or free-threaded) Python would be of great benefit, and the majority of the community seems in agreement. Threads have significant downsides and caveats, but they are widely adopte...
You know I’m using tensorflow and it seems to do a great job utilizing all my available cores. I know there’s underlying C code that makes that possible, but I don’t see why that’s a problem. This isn’t a weak point in python. World class C integration is one of the best things about python.
BECAUSE, as you’ve discovered, the part that does the actual calculations in parallel is indeed written in C/C++/CUDA. You are just using python as basically a glorified bash at that point (which is great, because that’s EXACTLY what it was designed for). Python is the PERFECT tool for that job.
There are people out there who want are not satisfied with that. They want to write THOSE performant bits (or ones like it) in pure python. Not with some compilable subset of the language or jit compiler, but with ACTUAL, interpreted, python code. There are people who want to write non-io-limited multi-threaded algorithms IN python. They all believe they are hamstrung by the GIL, and instead of just picking a (compiled w/ proper threading) language much better-suited for that particular job, they are perpetually trying to fit a round peg into a square hole.