5 ms·
My body is ready. I love python because the ease of writing and logic. Hopefully the more complicated free-threaded approach is comprehensive enough to write it
by Sparkyte 2y ago
My body is ready. I love python because the ease of writing and logic. Hopefully the more complicated free-threaded approach is comprehensive enough to write it like we traditionally write python. Not saying it is or isn't I just haven't dived enough into python multithreading because it is hard to put those demons back once you pull them out.
- ZhongXina 2y agoPrecisely, ease of writing, not ease of reading (the whole project, not just a tiny snippet of code) or supporting it long-term.
- ameliaquining 2y agoThe semantic changes are negligible for authors of Python code. All the complexity falls on the maintainers of the CPython interpreter and on authors of native extension modules.
- stavros 2y agoWell, I'm not looking forward to the day when I upgrade my Python and suddenly I have to debug a ton of fun race conditions.
- teaearlgraycold 2y agoIt's kept behind a flag. Hopefully will be forever.
- stavros 2y agoOh, very interesting, that's a great solution then.
- geekone 2y agoLooks like according to the PEP it may eventually be default in 4-6 releases down the road: https://peps.python.org/pep-0703/#python-build-modes https://peps.python.org/pep-0703/#python-build-modes
- metadat 2y agoThe article states the goal is to eventually (after some years of working out the major kinks and performance regressions) promote Free-Threaded Python to be the default cPython distribution.
- dagenix 2y agoAs I understand it, if your code would have race conditions with free threaded python, than it probably already has them.
- stavros 2y agoNot when there's a global interpreter lock.
- pdonis 2y agoThe GIL does not prevent race conditions in your Python code. It only prevents race conditions in internal data structures inside the interpreter and in atomic operations, i.e., operations that take a single Python bytecode. But many things that appear atomic in Python code take more than one Python bytecode. The GIL gives you no protection if you do such operations in multiple threads on the same object.
- stavros 2y agoI answered in a sibling reply: https://news.ycombinator.com/item?id=40950798 https://news.ycombinator.com/item?id=40950798
- pdonis 2y agoI'll respond there.
- vulnbludog 2y agoI’m a dummy don’t know nothing about coding but I love HN usernames lol
- matsemann 2y agoI think what many will experience, is that they want to switch to multithreading without GIL, but learn they have code that will have race conditions. But that don't have race conditions today, as it's run as multiple processes, and not threads. For instance our webserver. It uses multiple processes. Each request then can modify some global variable, use as cache or whatever, and only after it's completely done handling the request the same process will serve a new request. But when people see the GIL is gone, they probably would like to start using it. Can handle more requests without spamming processes / using beefy computer with lots of RAM etc. And then one might discover new race conditions one never really had before.
- hot_gril 2y agoWhat are the common use cases for threading in Python? I feel like that's a lower level tool than most Python projects would want, compared to asyncio or multiprocessing.Pool. JS is the most comparable thing to Python, and it got pretty darn far without threads.
- BugsJustFindMe 2y agoWorking with asyncio sucks when all you want is to be able to do some things in the background, possibly concurrently. You have to rewrite the worker code using those stupid async await keywords. It's an obnoxious constraint that completely breaks down when you want to use unaware libraries. The thread model is just a million times easier to use because you don't have to change the code.
- hot_gril 2y agoAsyncio is designed for things like webservers or UIs where some framework is probably already handling the main event loop. What are you doing where you just want to run something else in the background, and IPC isn't good enough?
- BugsJustFindMe 2y agoNon-blocking HTTP requests is an extremely common need, for instance. Why the hell did we need to reinvent special asyncio-aware request libraries for it? It's absolute madness. Thread pools are much easier to work with. > where some framework is probably already handling the main event loop This is both not really true and also irrelevant. When you need a flask (or whatever) request handler to do parallel work, asyncio is still pretty bullshit to use vs threads.
- hot_gril 2y agoNon-blocking HTTP request is the bread and butter use case for asyncio. Most JS projects are doing something like this, and they don't need to manage threads for it. You want to manage your own thread pool for this, or are you going to spawn and kill a thread every time you make a request?