I think all kinds of components and applications are going to hit the wall. The python interpreter doesn't even support multiple real threads let alone multiple cores. Programmers don't know how to write the code. Here is an article musing about the problems in Java: http://www.devwebsphere.com/devwebsphere/2006/11/multicore_m... Do we all need to learn erlang?
One of the few things I liked about Java was how easy it was to do multi-threaded programming. Granted it's clunky but Java network apps are much simpler than doing the same thing in C / C++.
I agree that Stackless is better. Threads are very heavyweight. The problem is that the underlying C interpreter works on only one core. If Stackless can work with multiple interpreters then it may be the greatest thing since sliced bread. I haven't been following it closely enough to say for sure.
All you have to do is build a mechanism that distributes threads between interpreter processes then just spawn an interpreter for each core. For many applications, that's all you need.
Python uses native threads which can be scheduled by the OS to multiple cores. It's just that can't run the interpreter at the same time (C-coded extensions can, and most of them release the lock).
It greatly depends on the task but my usage of the module is in disagreement with the PEP i.e., I don't use its threading-like API preferring its "distributed" capabilities.
The main point is there are multiple "concurrent" approaches and Java-like "threading" approach is the worst for many tasks i.e., It would be nice if GIL had been gone but for many "concurrent" approaches It doesn't matter. http://wiki.python.org/moin/ParallelProcessing
