The parent's statement is still technically right:

"python interpreter doesn't even support multiple real threads let alone multiple cores"

multiprocessing allows you to have the interpreter start another entire OS process (another interpreter). It mimics the threading API.

It's useful and it does allow you to take advantage of multiple cores without unfamiliar APIs which I take it is your point...

You can see in the PEP that for many situations the overhead of processes is not a big concern:

http://www.python.org/dev/peps/pep-0371/

multiprocessing module supports multiple "concurrent" programming paradigms.

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

The endless GIL debate: why not remove thread support instead? http://mail.python.org/pipermail/python-dev/2008-December/08...

I'm in agreement (note that I could not really tell what you were saying in your original comment).

If I need to do some tightly coupled thing with threads and shared data etc. I'm not going to be looking at Python anyhow.

I would love to have parallel list comprehensions, for instance.