>But don't fool yourself that "MOST" of anything works with any one architecture. It's a big world. Of methods of concurrency that people use, there are two ma

>But don't fool yourself that "MOST" of anything works with any one architecture. It's a big world. Of methods of concurrency that people use, there are two main approaches, threads, and multiprocessing. I just contend only about 15% of solutions are super clear winners for one or the other, leaving 65-70% of apps that can go either way. And I'm not a web developer, I'm an embedded software developer with years of experience in embedded video, streaming video, and hardware emulation. Lots of THAT stuff also fits just fine in either system too. As does the test systems, large analytics programs, etc that I've seen unrelated to the field. Actually python largely keeping to the inconsistency of the underlying OS with regards to mmap and other shared memory solutions is the biggest obstacles there. Oh, and the fact that hardcore numerics are still callouts to C libs in python. >And I assure you I've read Stevens. Lots and lots of people read Vol1, it seems like 1/10th as many read Vol2. Hell, I'm pretty sure most people who read Vol1 haven't a clue what's in Vol2. I'm by no means saying I want the GIL to say the same, I just think numerics work, graphics, games need threads, after that, you get to use either one (aka, 15% need threads, the other 85 need processes or can use either).