> Maybe for somewhat obscure multithreading cases.
They're only "somewhat obscure" because currently you can't do it at all, so you don't do it and you do something else: it's of value for any case where you're multithreading for computational parallelism (as opposed to IO concurrency). The PEP also outlines a bunch of other situations where using process-based parallelism is problematic: https://peps.python.org/pep-0703/#motivation
With the proviso that while it will work for all pure-python code out of the box[0] loading any native package which has not opted into "no gil" mode will re-enable the GIL: https://peps.python.org/pep-0703/#py-mod-gil-slot
[0] modulo new race conditions where the code relied on the GIL for correctness, something which isn't strictly correct and can already break when the scheduler logic changes
Is not true. First of all, Python threads are mapped to OS threads. So, you can do "something". Now, in CPython C API there are tools for releasing and acquiring the global lock. They aren't complicated, and I used them in my own extensions. Not sure how popular across other extensions is this practice, but, at least some do use it. Some Python native functions release and acquire this lock while running in non-main thread. For the most part, it's the functions that perform blocking I/O.
To sum this up and to make it easier to conceptualize, I describe this as Python can sleep concurrently, but can do no work concurrently.
As to "obscure multithreading cases"... well, ironically, some Python libraries use Python threads unironically... I believe Paramico uses them, but this is from memory, so please don't blame me if that's not the case. It's not very popular, but some have actually used threads. Typically it gives you no benefits when using Python, but on an odd day... There's also a thing about when Python threads can switch, which makes certain code impossible to race, but also makes some particular edge cases of errors harder to reproduce.
So, developers working on libraries that don't use any multithreading will probably not notice, but, these cases are rare because Python is on the path of dependency bloat. Which means that in a large enough project, you are bound to get a library that uses threads. And then you will be impacted by the bugs in multithreading even though you, personally, had nothing to do with it.
You can only do "something" if that doesn't involve interpreting actual Python code. Which is a pretty big deal since we're talking about Python programming.
Modern Python programming is highly reliable on all sorts of tricks that don't involve interpreting Python code -- all sorts of strap-on JIT compilations, interpreting code in some other interpreter (not Python)... or just compiling Python ahead of time.
Python library functions evolved from being simple and somewhat transparent into hugely complicated environments, possibly with their own interpreters that can be programmed by the same programmer who writes the Python program.
While this is an unguided, hugely inefficient ad hoc process, it is this whole mess. Thus, people who write "Python programs" are actually writing programs in Python + a bunch of crappy unter-languages that operate at or even cross different layers of abstraction. And we still call this "mess" a Python program. Eg. Jinja templates or Nuitka decorators or IPython "magic" or Cython etc.
So, in practical terms, there's a lot of what's going on in a Python program, because often a lot and sometimes most of it isn't written in Python proper, Python is just a kind of entry point to that mess, and is used as a label for a thing that nobody cared to give a proper name.
They're only "somewhat obscure" because currently you can't do it at all, so you don't do it and you do something else: it's of value for any case where you're multithreading for computational parallelism (as opposed to IO concurrency). The PEP also outlines a bunch of other situations where using process-based parallelism is problematic: https://peps.python.org/pep-0703/#motivation
With the proviso that while it will work for all pure-python code out of the box[0] loading any native package which has not opted into "no gil" mode will re-enable the GIL: https://peps.python.org/pep-0703/#py-mod-gil-slot
[0] modulo new race conditions where the code relied on the GIL for correctness, something which isn't strictly correct and can already break when the scheduler logic changes