Here’s a great article from Thomas Ptacek at Matasano entitled: Typing The Letters A-E-S Into Your Code? You’re Doing It Wrong!
This is one of the talks that was presented at PyCon 2009. Ned walks you through examining how much code your unit tests actually cover. As we become more “testing aware,” a portion of the community is really starting to focus on numbers. In particular, 100% test coverage, as though it were some panacea. Ned points out how that is a fallacy, and shows a couple of examples of how you can have 100% coverage and still be broken (it’s the paths through your code that matter… and it would be nearly impossible to test them all). Ned’s talk isn’t the only one out there about this sort of thing, which is a Good Thing. There needs to be a lot of discussion about this so that we don’t forget that once we get to 100%, we can still do better.
Just did a quick hack to make Python use native Mach semaphores for the GIL instead of the mutex/condition variable pair, and got sizable speed up (13%) on David Beazley’s thread test from his presentation (I have 4 cores instead of 2 though). Guess I need to create a patch to add support for it.
Another great article appeared in the April issue of Python Magazine. This time it was written by Paul McGuire, author of pyparsing. The article is called Create your own Domain Specific Language in Python with imputil and pyparsing. It’s a fairly long article, but it walked through the steps of generating a language to describe state machines. The author used pyparsing to extend the Python language to add a state machine construct that is intermingled with real Python source code. He stored these extended source files as .pystate files instead of .py files, and then hooked the module import process with imputil to allow him to import .pystate files and have pyparsing automatically transform .pystate files into real python code.