So if you had the string

POST /wfs?request=Null&log&foo:bar=1,2:3,2:4,2&baz=x,y:y,z

and wanted to turn it into the list

['foo:bar:1,2', 'foo:bar:3,2', 'foo:bar:4,2', 'baz:x,y', 'baz:y,z']

How could you do it? Well, you could define a grammar & pass that into a parser... or you could have a pile or for loops.... Or, how about a triply-nested list comprehension contained within a reduce call? Like this!!!

reduce(operator.add,
       [[(tag + ':' + value) for value in values.split(':')]
        for (tag, values)
        in [b.split('=') for b in a.split('&')[2:]]])

Lately I've been doing some Python multi-threading to make the best use of some of our amazing server resources. As I was pondering the reasons why one of our 8-core servers reported 83% idle despite 8 threads banging away, I re-discovered the Global Interpreter Lock.

BLECH!

The GIL enforces Python's requirement that only a single bytecode operation is executed at a time. My nicely coded multi-threaded app was only being executed serially!! Sadly, this seems unlikely to change, even in Python 3000. Last year Guido said:

"Just Say No to the combined evils of locking, deadlocks, lock granularity, livelocks, nondeterminism and race conditions."

I was brought up to believe that threading was dirty and independent communicating processes were the way to go. But even I realize that this just isn't practical in these days of GUIs, multi-core processors, and application servers.

Why does the Python community accept the GIL? Is it because most people only use Python as a scripting language? Are there simple workarounds (e.g. not forking, shared memory, or the like) that I'm missing?