.webp?h=8 "Merry Fistmas!")
I'm working on a project in Python and there's a very obvious, almost textbook, spot to throw in some concurrency. I'm allergic to reading documentation and most of my code comes from modifying stackoverflow snippets so I perhaps naively googled "python threading" and implemented that. Imagine my surprise when I got literally no performance gain. So I looked into it and it turns out threads in Python are just fake threads, the entire program still runs in a single thread. You get all the overhead of concurrency with none of the benefits.
So I switched over to the multiprocessing library, which thankfully was pretty painless since it works almost identically to the threads library except with, you know, actual concurrency. That started out ok but I ran into trouble trying to return complex objects from the spawned processes. You can return simple data types pretty easily in a thread safe way, and even objects composed of simple data types, but trying to return an object that contains another object simply doesn't work. So once again I looked into it more and it turns out I have to specifically use a SyncManager if I want to return complex objects. So once again I implement that and it finally fricking works after hours of mucking around in the shit.
Why are there like 30 different ways to do concurrency in Python, with most of them sucking butt or not working at all? I've done concurrency in lots of other languages and they're all very straightforward. Even fricking C++ makes it easy to implement.
Jump in the discussion.
No email address required.
Python has never EVER been about multi-threaded performance. It's why I strictly use it only as a script language or a very very small none computationally intensive app. Any bullshit about throwing cocurrence on top is just cope.
Jump in the discussion.
No email address required.
More options
Context