It's already easy to write race conditions in Python.

  if x in d:
      del d[x]
  else:
      d[x] = True

Is a classic example -- if two threads execute that, you can't predict the outcome (but a KeyError is quite likely)

The GIL only protects the CPython virtual machine; it doesn't protect user code. Concurrent code with shared mutable state already needs explicit mutexes.

What thread safe code can I write with the GIL that will have a race without it?

I already have to be careful to only write to a shared object from one thread, since I have no guarantees on order of execution.

The main benefit of the GIL, from my recent reading is that it makes ref counting fast and thread safe. The meat of the proposal is changing ref counting so that it's almost as fast and atomic without the GIL.

What about setting a simple boolean flag, e.g. setting "cancelled = True" in the UI thread to cancel an operation in a background thread?

In Java you would have to worry about safe publication to make the change visible to the other thread, but thanks to the GIL changes in Python are always (I think?) made visible to other threads.

changes are always eventually made visible to other threads in all modern languages - it's the timing of thread wakeup and the possibility that the thread may not flush a cache that is uncertain. the GIL doesn't magically solve race conditions, and in Java and other such languages, you usually have a keyword like volatile that can make flushes explicit. In any case, I very much doubt the GIL work would affect Python's cache coherency model.

here's a python code that would break even with GIL:

current_boolean_value = global_cancelled

global_cancelled = new_boolean_value(current_boolean_value)

The GIL is not a feature but a design problem with both Ruby and Python. Implementations of both without a GIL have existed for quite long (e.g. jvm based implementations like jython and jruby). It's fine; not having a GIL is an enabler. E.g. being able to run ruby on rails on an application server with threads for each connection used to be a popular thing. I've migrated a few ruby things to jruby. It's shockingly easy. Mostly stuff just works.

The nice thing about everything being single threaded is that nothing will break if you remove the GIL. It will still be single threaded. It's only when you actively start using multiple threads that things might break. So, you won't have race conditions until you do that and then only if you do things that you shouldn't be doing like sharing things across threads that you should not be sharing because they aren't thread safe.

Removing the GIL will simply enable people to start gradually fixing things and give them the option to use threads instead of forcing them to use completely different languages.

Ractor style asynchronous programming might be a good idea for python as well. One does not exclude the other.

No new race conditions are expected as this work replaces Gil with finer grained performant locks. It still lowers performance of single threaded code some vs no Gil (about 10 percent) but 10 percent drop in single threaded performance is worth considering for multi threading.

The race conditions a Gil program and a no Gil program should have should be same. A Gil is not the only way to keep certain operations safe.

> but 10 percent drop in single threaded performance is worth considering for multi threading.

Only if you are writing multithreaded coded. Otherwise it is just a loss.

It is trade off. Pure single threaded code is worse in exchange for much better multithreaded code. And the current sentiment in the python dev mailing list looks positive. Previous attempts at Gil removal had much bigger drop in single threaded performance.