6 ms·
The 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
by ameliaquining 2y ago
The 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.