In Python, threading will not help you if it's a compute-intensive task because of the global interpreter lock, which prevents parallelization.  Better to reach for Cython before threading, at which point you probably don't need threading anymore.  In general threads are not actually advantageous to games because the nature of games is that things happen before other things, and the order of events matters.

I don't have good resources because it's been too long, but in general threading is very much a here there be dragons sort of thing that's best avoided if at all possible, unless you're using some sort of abstraction library (i.e. Rust's Rayon, Intel TBB, etc).  In general I would strongly suggest that any new programmer (and you count, by my standards) stay away from it unless there is no choice.  To get some idea, google data race and deadlock.  You will discover that most of the hello world of threading is esoteric, because it's only in the world of academia that we can construct problems where you can cleanly explore threading.  You'll find yourself saying things like "But surely I can just put a lock on everything!", and then discovering, months down the road, that you couldn't because they're expensive, or that part of the engine isn't architected right for concurrency but was architected right enough that it seemed like a good idea at the time.  Most threading bugs can't be duplicated on demand, and you're often lucky if it will even happen on your machine at all.  I have literally written scripts that start the program 100+ times and do something to it, so that I could hit it and wait a couple minutes to get the program into the bugged state and figure out why it's broken, and I will almost certainly do so again.  Put simply, threads are a project killer, and learning to use them in anger will kill the first project you try to use them in (this is why camlorn_audio stopped being a thing,).

And even if you get a working implementation, it's often slower than if you hadn't, due to overhead of synchronization.  Which is part of what would have had to be fixed in Libaudioverse if I was continuing that, and why most people who used it ended up turning off threads--you could run 1000 sources with it fine, but for 10 or 20 it was 2x or more slower than just not having parallelism.

But that said, that's not a helpful answer.  So first, you have 1 of 2 kinds of problems that are making you ask.

The first kind of problem is "I want to simulate 10000 objects".  You can solve this with better algorithms (i.e. spatial hashes) for which libraries already exist, cython (which compiles your Python to C and gives you around 100x or more times the performance for this kind of thing), and increasing the time between game ticks (basically tick 10 times instead of 20, but move objects twice as far).  Python multithreading doesn't get you compute-level parallelism, if you want that you need to use the multiprocessing module (which doesn't give you shared state, i.e. no way for all the threads to see the same game) or Numba/TensorFlow/Theano/etc (which are easy to use but don't redistribute well if at all).

The second kind of problem is that you want to do networking or something and it's too slow.  You solve networking by using async networking libraries or with threads, which I'll get to in a second.  Pick up asyncio or something.  If it's file I/O, you do less file I/O during the game loop (i.e. don't try to save everything after every tick).  File I/O is a lost cause even with threads involved.  Fortunately if you do need threads for this Python threads are fine.

If you do use threads, the safest way is to think of threads like entirely separate programs.  Then you use Python's Queue module to communicate between them.  Alternatively find a parallel mapreduce implementation (and learn what mapreduce is).  Multiprocessing.dummy in Python's standard library can be used for mapreduce, because it offers the mutliprocessing API on threads.

But, to be honest, you're very far from the first person to worry about performance first, and I can't think of a single case in audiogame history where the answer was "you should use threads".  it's almost always "did you know about this faster algorithm" and that's the end of it.  Start by having the problem before you try to solve it, because what you're talking about getting into gives career programmers with 5+ years experience nightmares, and it's literally easier to go use Rust or C++ or something than to try threads.  You won't need to switch languages either.  But *if* you can't make Python fast enough for what you're contemplating and if Cython was somehow not enough, it would be easier to switch to C/C++ for your problem than to use threads (and for everyone who is going to say "but java or C#": yes, but threads are hard in Java or C# too, and if Cython isn't fast enough neither of those will be either).  Start by telling us what the actual problem is, and by writing a benchmark of what you propose to do.

In general I'm not against people knowing about threads, indeed part of my job involves them in great detail and it's the kind of thing that gets you into Google, but I would honestly say it took me multiple years to be able to use them without screwing up, significantly longer than almost anything else I've learned to do, so if your goal is to get something finished don't use them, or if you have to limit where you have to use them as much as possible so that your mistakes don't kill everything forever.

Thank you. As I said, I wasn't very experienced in things of that nature, and I also don't know too much about computer performance and hardware in general. I'll look into Cython and other such things as per your responses.