The problem is the GIL prevents threads from making progress simultaneously, even with synchronization and locking primitives available.
But even so, Python is a little slow when you start thinking about threading. You'd be better off using Rust or Go or something rather than the half-baked support found in scripting languages.
> the half-baked support found in scripting languages.
It's a long time since I've heard that phrase used disparagingly. Didn't we all decide to use the term "dynamic languages" just to avoid the judgemental overtones associated with "scripting".
> It's a long time since I've heard that phrase used disparagingly. Didn't we all decide to use the term "dynamic languages" just to avoid the judgemental overtones associated with "scripting".
I didn't mean to disparage. While I did intend to scrutinize Python's multiprocessing (my experience with it was less than fun), my use of the term "scripting language" was entirely subconscious.
But I do have an anecdote.
A decade ago I was using Python and Flask for building web apps. Now I use Rust instead, and many of my collages are choosing to use Go.
I still use Python for scripting and now also use it for ML. But I wouldn't use it for the web anymore.
I think the landscapes and use cases are shifting since there are new tools available. Python is doing new things (pytorch, tensorflow), but less of the things I used to use it for (Flask, Django, ...)
But even so, Python is a little slow when you start thinking about threading. You'd be better off using Rust or Go or something rather than the half-baked support found in scripting languages.