Nice article and very helpful how you included CPython code for background.
I think, though, that your statement about list.sort() being atomic is not accurate. In a preempt-able scenario with multiple threads, there's nothing preventing thread 1 from starting to sort the list in-place, runs out of the 1000 bytecodes or 15ms that's allocated to it, and then another thread becomes the currently running thread and appends an item to it. This would be a problem. An external locking mechanism is needed to guarantee the list.sort() function is not interrupted.
From the documentation:
"CPython implementation detail: While a list is being sorted, the effect of attempting to mutate, or even inspect, the list is undefined. The C implementation of Python makes the list appear empty for the duration, and raises ValueError if it can detect that the list has been mutated during a sort."
Thanks for clarifying. This makes sense as long as the GIL will not be relinquished in the CPython code, which from your other examples seems to only be done consciously by IO-dependent code, which I take from what you've written to be the case.