Comment by superbatfish
5 days ago
This is accurate and the parent commenter here seems to be echoing a common misconception. Either they are confused or they need to elaborate more to demonstrate that they have a valid complaint.
For instance, this would have been a valid complaint:
"Users who don't need free threading will now suffer a performance penalty for their single-threaded code."
That is true. But if you are currently using multiple threads, code that was correct before will still be correct in the free threaded build, and code that was incorrect before will still be incorrect.
I got it wrong too, even after reading the docs, until I just tried it for myself. Intuitively, why would Python have threads that can't run fully in parallel but also create race conditions? Seems like the worst of both worlds, and it almost is, except you can still speed up io-bound or even GIL-releasing CPU-bound C calls this way.
Some also mix it up with async JS which also can't use multiple CPUs and guarantees in-order execution until you "await" something. Well now that's asyncio in Python. Doesn't help that so much literature uses muddy terms like "async programming."