←back to thread

The first year of free-threaded Python

(labs.quansight.org)
291 points rbanffy | 2 comments | 16 May 25 09:42 UTC | HN request time: 0.422s | 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 #
seabrookmx ◴[17 May 25 00:23 UTC] No.44011009[source]▶
While it certainly has its rough edges, I'm a big asyncio user. So I'll be over here happily writing concurrent python that's single threaded, ie. pretending my Python is nodejs.

For the web/network workloads most of us write, I'd highly recommend this.

replies(1): >>44013078 #
dontlaugh ◴[17 May 25 09:15 UTC] No.44013078[source]▶
Asyncio being able to use thread pools would reduce memory usage at the very least.
replies(1): >>44019174 #
1. seabrookmx ◴[18 May 25 05:22 UTC] No.44019174[source]▶
How so? As opposed to running multiple processes you mean?
replies(1): >>44019645 #
2. dontlaugh ◴[18 May 25 07:32 UTC] No.44019645[source]▶
Exactly, you could do like other runtimes and run a single process that can saturate all cores.

You wouldn’t be duplicating the interpreter, your code, config, etc.