> It only made it appears more infrequently.

It makes some operations atomic which is quite relevant.

Fewer than people expect. For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here.

> For example, the += operator looks atomic, but under the hood, it's made up of multiple python bytecode instructions, so the GIL won't apply here.

Sure, but any call to a native function which doesn’t release the gil (which is most of them at least for the builtins) is currently atomic so something like dict.setdefault.

Those would have to remain atomic by taking explicit more granular locks.

Obviously?

But the point is currently they do work, they are thread-safe and they are correct in the strictest sense of the word, per-FAQ: https://docs.python.org/3/faq/library.html#what-kinds-of-glo...

So as the original commenter notes:

> wouldn't removing the GIL cause all sorts of sudden race conditions and regressions in existing python code?

And note that this is mentioned in the faq.