Where does the GIL factor into this? I thought using threads in Python gives basically no gains unless all the heavy work is being done outside the interpreter. I've always gone with the multiprocessing module instead.
Python threads are only useful if you use C modules that handle the GIL correctly and I/O bound stuff from the standard library, it gives no speed boost for python code
here's one more usecase which is probably very common: When you use python as glue to call other programs which can run asynchronously. As an example I've used python once to implement a parallelized genetic algorithm where the evaluation function was a matlab program. It was quite a breeze to spawn hundreds of such threads over ssh using one PC as the controller - if only I hadn't shocked the local sysadmins ;-).
Sorry, but you this is misguided. You are almost certainly using an OS that gives you concurrency, even if you only have one core of execution on your cpu. Concurrency is only natural, and is in fact a requirement when you start talking about GUIs. Even for something like data processing, you usually have a thread doing the processing, and another thread controlling everything. The advantage of threads is the natural separation of tasks, simplifying how programs are written. Not having the advantage of performance in python is unfortunate, however this is only one use for threads, which is by far not the most common.
This stems back to parallelism vs. concurrency. Yes, it is true that your Python threads will not run in parallel but they will run concurrently. If you're curious about parallelism vs. concurrency, here is a great talk by Rob Pike on the subject: http://vimeo.com/49718712