I never get why people are so fanatical for or against threads - they are a useful tool in the right place. That said Python has a wealth of alternatives - if you are I/O bound asynchronous is usually the best way to go, co-routines and generators are showing a lot of promise and greenlets look good as well.
Debugging threads is a skill like any other - it is quite hard at first but with practice it becomes second nature. And don't let anyone tell you that the alternatives are any easier - I have a twisted crawler that is (necessarily) just as complex (and capable of 'mysterious' problems) as any threaded app I have built. And I am very experienced at building both.
I think the main reason there's no Thread.kill is that Python threads are implemented using OS threads, and there's no cross-platform way to kill native threads. Giles might have been thinking of the Java API, which has stop (although I think it's a holdover from when Java threads were implemented as 'green' (non-native) threads - like Ruby's are now). Even in Java, Thread.stop is deprecated.
Generally, the idiomatic way to stop a thread is to do it cooperatively - you set a flag which the thread promises to check periodically. Another common situation is that you're feeding 'work-items' to a worker thread via a Queue - in that case a simple way to stop the thread is to place a sentinel value that means stop into the job queue. Those two tend to cover most cases.
"pathological hatred"? "prejudice"? "loathing"? Nice to know I come across as some kind of foaming-at-the-mouth loon. :-|
I just hate gratuitous complicatedness, and that's all shared-state, preemptive multithreading buys us.
Oh jeez, I'm foaming again, where's that napkin?
I can absolutely agree with that - if you're using threads, you should emulate shared-nothing concurrency (with Queues as your in- and outputs). Otherwise it just opens up a world of pain.
I agree with not being allowed to kill threads. A dead thread can't execute its finally clauses, and can't nescessarily release locks and references it holds. Think about what might happen if Python code calls a library function implemented in C, which calls back to Python code. And shudder. It is at odds with the normal Python philosophy of allowing the developer to shoot themselves in the foot any time they want to, but, on the bright side, there are still plenty of other ways to take down a Python VM from the inside.
As far as threads in general goes. I am ambivalent toward them, because I am a Java programmer, and if I allowed myself to hate them, I would go mad. xtian, above, has some good advice.
If you do need to kill the thread running the code under test, you may be better off forking a process (though you probably thought of that already.)
Cool. Thanks for your comments guys, very interesting. One of the advantages of having a blog is that I can spout off in my ignorance and have you guys teach me for free 
I should probably put my oar in, as I've been quoted 
I'd argue very heatedly that having the ability to non-cooperatively kill a thread is essential to any threading API - but at the same time, I'd argue just as heatedly against *almost any* use of it. In fact, on reflecion, I think I'd be very uncomfortable about its use in any case apart from recovery from bugs in the thread that is being killed.
It's rather like "kill -9"; when everything is working correctly under your Unix system, you should never need it - all processes that you want to terminate will terminate correctly if you use kill without the -9 flag, or send them an appropriate shutdown message some other way. But under emergency conditions, it can be justifiable to use kill -9.
Similarly, if you're trying to recover a system from some critical error, you may need to shut down a thread that's doing something destructive - and is doing it in such a way that it's just not listening to any "please stop yourself" flag you put in there. Being able to stop the thread preemptively is an emergency workaround to allow you, in a support role, to recover from a bug that you created in your developer role.
I like very much Python's lack of restrictions on what the programmer can do, and the lack of a kill() method on the Thread class seemed to go against that - though I now realise that it may have been left out for other reasons.
Xtian's point about the lack of cross-platform support is a good one, - but Java has kept the .stop() method despite moving from green threads to native ones, so it must be possible. I can certainly imagine that it might be tricky enough to put it pretty low on the development queue, though.
Regarding Java's deprecation of the .stop() (etc) methods - I'd say that's actually very much a sign of the Java "don't let the programmer do anything that might let them hurt themselves" attitute. There's reason behind it, but if you start heading in that direction you find yourself programming in Pascal :-S
Sorry, a bit incoherent, but I hope my point gets across.
Commenting by HaloScan
