Where is this demand exactly? We hear a lot of complaining but very often this is due to a lack of awareness of available (& often better) alternatives to threading.
There is a very small number of use cases that will benefit from free threading.
The motivation summary of PEP-703 contains some material on this:
https://peps.python.org/pep-0703/#motivation
Further discussions going back years can be found with a brief search. This discussion is almost as old as Python3.
> due to a lack of awareness of available (& often better) alternatives to threading.
Such as?
There are exactly 2: asyncio, which is useless for CPU/GPU bound workloads, and multiprocessing with all the pain of relying on expensive spawns, expensive and limited IPC and the joy of having to orchestrate across process boundaries.
Guess what the most common advice is for dealing with CPU bound parallelisation problems in Python? "Use another language". Guess what all the languages recommended (C, C++, Rust, Go, Java) have in common? They have thread-based parallelism.
> There is a very small number of use cases that will benefit from free threading.
Basically any workload that is CPU bound, which in the day and age of giant data aggragation and running huge ML models at scale is more important than every before, is a use case for this.
Right, because the whole point of Python is as a glue language for native libraries. Adding multi threading to Python is like adding to to Bash.
I have had this precise need before. I have a multi-threaded native library. The multi-threading is essential for reasonable performance in the intended use-case for the library. But my users can't write C++ to call it; they'd like Python. They'd like to extend certain specific operations that my native library does during processing. I give them Python bindings. The perf gained by running the library on multiple cores is completely negated whenever multiple C++ threads of my native library need to run Python code.