3 ms·

No-GIL means better performance at the cost of being less beginner-friendly, right?

• Waterluvian 3y ago
  Not really. The GIL doesn’t actually make threading easier for a typical developer as they still have to worry about thread safety. You can ignore locks if you know what Python operations are atomic. But that’s incredibly perilous and you really shouldn’t try given that relies on implementation details. Eg. What if you didn’t realize a setter was overridden and setting to a dict-like isn’t atomic anymore? It’ll make the Python source code much more complex and complicated, which is probably not a big deal, though I’ll say the CPython source is quite brilliant. It’ll also mean for C library developers that they can’t assume Python opcodes are atomic. But I’m not sure C library developers will really mind too much because they already worry about this kind of stuff.
• JamesSwift 3y ago
  I think multi-threadedness is already an intermediate level concept so maybe its not a big downside. In turn, the ones that understand and need the performance get it.
• tedivm 3y ago
  Only if the user explicitly uses threads. By default people can still approach their code in the exact same way they do. I imagine most users won't think about threads at all, but may relay on frameworks and libraries that take advantage of them under the hood.
• qbasic_forever 3y ago
  It's only more performance if you're using the threading primitives and spawning new threads, moving work to them to do in parallel, etc.--this isn't something any beginner will consciously be doing. It might actually be slower in regular single process use that 99% of python users use (since the GIL is there for a very good reason and synchronizing access to python's internal state doesn't just happen for free or without some cost somewhere).