So here's the situation. I'm making a game that mixes two genres; arcade shooter and puzzler. They don't intertwine TOO much; all the interaction that really goes on is that every time an enemy is destroyed, a block is created. The blocks aren't even a part of the main collision detection system; they have their own more suited to their needs. What I want to ask is this; might it be a good idea to have the arcade shooter portion run on one thread, and the puzzle game portion run on another?
Probably not, unless you want to create extra work for yourself.
Threading is an optimization, which adds significant complexity to the program, and if you don't move the right thing on to another thread it won't even add much performance. The only way to know what the right thing to optimize is, is to use a profiler.
If you do want to use threads to improve performance a task based approach is what I'd recommend.
For example, let's say that for example once you've finished writing the game you find that the arcade game code takes 20ms / frame, and the puzzle game code takes 2ms / frame. That gives a total frame time of 22ms. In that case at best moving the puzzle game to another thread saves you 10% of the frame time. However if you could split the arcade game across two threads that could gain you up to 10ms.
The task based approach has the potential for even better performance, because it can easily scale to more than two threads.
It's also worth noting that games are generally not easy to split across multiple threads, and there's much better ways to optimize Python code than using threads - for example rewriting the expensive parts of the code in a lower level language like C/C++ can give huge gains.
In addition to what Adam has already said in his answer (and especially the second paragraph), it's worth noting that Python does not scale well with threads at all, because there is a global lock shared across all Python threads so that only one can run at a time, except under certain conditions. So the answer to any question like "Multithreading for XYZ in Python?" is almost always 'No'.
I'll add one thing - multithreading can indeed be used as a way to improve code organisation. But this is almost exclusively to allow a linear process to run in parallel with other processes that don't share many resources. Your situation doesn't seem to resemble this in that neither process is linear, and that you are likely to have many shared resources (eg. screen, input devices, sound system). As such it is probably better to go with the usual time-sliced approach.
First: Threads and processes are different on different platforms, and there is an advantage to using processes on Linux and a disadvantage on Windows. So your intended platform may drive which one you should use.
The general rule of thumb is that if you are hardware-bound, you should split blocking tasks off into their own thread. If you are computation-bound, you should split high computation tasks off into their own process.
Second: Adding concurrent processes of any sort adds complexity because you are inherently creating an asynchronous condition that requires synchronization. In other words, you must share data and time across the various tasks. Unfortunately, the programmer must explicitly identify and create a design for these tasks to communicate with each other.
Third: Testing and especially debugging becomes much harder because the tasks run independently of each other and obtaining state information for each task and the system itself is much more complex. This often means that you must increase your verbosity for logging and traces.
The general consensus is that you should not optimize your code too early. In other words, design your code as modular as possible, but do not add the extra complexity of threading until you realize that you must.