Comments

It's this kind of bullshit that makes me want to move on from python to something like Scala. Compare:

Q. How do we make software reliable?

Python A: make sure your code recovers quickly after crashing

Scala A: use Software Transactional Memory, to mark a block as a single transaction. Simply undo the current transaction if anything goes wrong, then continue from that point.

Q. How do we write programs that scale to high performance on multiple cores?

Python A: Well, we have the GIL which prevents proper multithreading, and actually makes threads SLOWER on multicore machines, but removing the GIL is hard, even though Jython did it just fine, so we're not going to bother. In short, we have lots of libraries for green threads etc., but none of them work because we won't fix the fundamental problems underlying it all.

Scala A: We solve the problem on two fronts. First, we the best of breed Actor model of concurrency, unifying it into the language core, with two main keywords allowing you to choose between heavyweight OS threads and lightweight "green" threads, allowing you to code in the same style no matter which system you need for a particular block of code. Secondly, we provide parallel collections, which allow you to, for instance, iterate over a list, running a block of code on it in parallel, just as you would with non-parallel code.

If you're interested in integrating STM into Python, see this (http://jjinux.blogspot.com/2012/03/pycon-why-pypy-by-example.html).

I don't think that having code to recover from crashes quickly is at odds with other approaches to reliable software. For instance, Erlang has an actor-based concurrency model, and Erlang OTP is all about trees of actors that monitor each other and recover from failures quickly.