So, in a previous post I said I’d likely chose git as my dvcs of choice. Well, it’s been almost 2 months and I find that while I’m very happy with the speed of git, it’s command line is more than I care to understand at the moment. I can get by with just a handful of commands, and on projects that are using git, I’ll do exactly that.
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.