←back to thread

The first year of free-threaded Python

(labs.quansight.org)
256 points rbanffy | 1 comments | 16 May 25 09:42 UTC | HN request time: 0.264s | source
Show context
AlexanderDhoore ◴[16 May 25 11:03 UTC] No.44003888[source]▶
Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.
replies(19): >>44003924 #>>44003936 #>>44003940 #>>44003943 #>>44003945 #>>44003958 #>>44003971 #>>44004203 #>>44004251 #>>44004431 #>>44004501 #>>44005012 #>>44005100 #>>44005259 #>>44005773 #>>44006165 #>>44007388 #>>44011009 #>>44011917 #
freeone3000 ◴[16 May 25 12:16 UTC] No.44004501[source]▶
I'm sure you'll be happy using the last language that has to fork() in order to thread. We've only had consumer-level multicore processors for 20 years, after all.
replies(2): >>44005842 #>>44011887 #
1. im3w1l ◴[16 May 25 14:19 UTC] No.44005842[source]▶
You have to understand that people come from very different angles with python. Some people write web servers where in python, where speed equals money saved. Other people write little UI apps that where speed is a complete non-issue. Yet others write aiml code that spends most of its time in gpu code. But then they want to do just a little data massaging in python which can easily bottleneck the whole thing. And some people people write scripts that don't use a .env but rather os-libraries.