> I think that attitude was a result of multi-thread scalability
> being hard, not the reason.
One part of "hard" is that threading support can slow down things for everybody, also people who don't use threads (who most likely are the majority of users of any programming language). And there are also other approaches for solving performance and concurrency issues than threading.
While there are some specific cases where threads fit nicely, people overuse them. I've understood that to be some kind of Windows legacy because on Windows process overhead (at least earlier) was too high and threads got marketed & popularized as a solution for performance issues although the issue they solved was mostly Windows specific?
> When people encounter problems they can't solve, they go into denial.
Or when they need to debug somebody else's threaded code, they may decide that advantages of threading are much over marketed compared to its disadvantages, such as heisenbugs & problems in testing; 100% coverage not being able to flush out race conditions, performance issues from lock contention and additional overhead from locking in general, level of threading support in underlying libraries etc.
What kind of performance issues you have?
Besides using separate processes to implement concurrency, there's Stackless Python which provides micro threads & coroutines. Nowadays there's also PyPy which is supposed to provide many of the same features.
Using a separate python interpreter implementation may be a problem though...
Then there's MP. Eclipse IDE even seems to have separate support for it (OpenMP):
Which might be useful if one wants to write a parallelizing Python module that's (hopefully) safer & easier to maintain than a threaded one.
 When people extol on advantages of some feature (like threading) they often forget than they need to be maintained too, and maintaining, for example debugging, requires *good* tools for that specific purpose. What tools there are for debugging threading issues?
I know Valgrind has two tools for detecting data races (Helgrind & DRD), there's mutrace to find out lock contention issues and Gdb naturally can give backtraces to all of the threads, but these are all run-time tools. Even in the best case they can find the problems only if your tests trigger them.
Are there any (good) open source static tools for analyzing threading issues in code?