« | » Main « | »

Coverage.py v3.3: .coveragerc files

Wednesday 24 February 2010

Coverage.py v3.3 is ready. It has two new features, support for .coveragerc configuration files, and a way to start coverage measurement automatically when Python starts. These work together to make it possible to measure coverage in subprocesses started by your test suite.

I had been hoping to get more features into this release, but at PyCon, Dirkjan Ochtman made it clear that it would help Mercurial's test suite if these two features were released, so here they are.

Back from PyCon 2010

Monday 22 February 2010

I'm back from PyCon 2010. It was a great three days. I had a chance to talk to tons of people about coverage.py, or testing in general, or just chat. It's really true that the "hallway track" is the best part of PyCon. The formal presentations will be available on video later anyway, and there's not much opportunity for interaction. Meeting people face-to-face is a rare opportunity and really builds the community.

Every year at PyCon there seem to be strong themes, not by design, but because of the community's current focus. This year they seemed to be packaging, concurrency, and speed. There was a lot of discussion about threading, asynchronous activity, eventlets, and so on.

Last year seemed to be about the alternative Python implementations. This year, they were present, with status talks as part of the plenaries, but were just an accepted part of the Python eco-system. I think this has had a positive effect, even on CPython. There's a new GIL implementation in 3.x, and I can't help but think that the idea of completely different implementations of all of Python helped grease the skids for re-implementations of central parts of CPython.

I decided on the spur of the moment to do a lightning talk about the last year of progress on coverage.py, video here, I start at about 19:40. Lightning talks are fun: they're fast, spirited, and can be (far) less serious than the formal presentations. But it was a little terrifying being on the big stage, knowing you have only 5 minutes to talk, and that you'll be cut off unceremoniously if you go over. As it was, I finished with 0:05 on the clock!

I met with other local users' group organizers in an open space. It was cool to see the positive energy they each brought to the job, and to hear other ideas for bringing Pythonistas together.

I gave a talk on Saturday, Tests and Testability, which seemed to be well received. There was an interesting dynamic afterward, because people who saw the talk assumed I was an expert on testing, and had all sorts of difficult questions for me. The fact is, I'm not a testing expert, just an eager learner. I wanted to talk about testability not because I know all about it, but because it's a topic I struggle with myself, so it's on my mind quite a bit. I did the talk because I'm learning about testability myself. In the talk, I energetically described what I've learned, but afterward, I felt like I was learning from the questioners as much as they were learning from me.

The Saturday night Testing in Python open space was the usual rowdy party, with lightning talks and extended heckling from the crowd. I missed the first hour, but the bits I saw were good. Andrew Dalke and I talked about nitty-gritty details of grokking the structure of Python programs, and he's got an interesting start on a different approach to coverage measurement.

Dirkjan Ochtman and I had been exchanging emails about getting tricky parts of the Mercurial test suite coverage tested. We managed to get together one evening and worked through the problems. If we had been caught up on our sleep, it probably would have taken about 15 minutes, but it was a fun way to spend three hours anyway! Dirkjan convinced me to release the next version of coverage.py quickly so that he could use it for real, so that should happen in the next few days.

I also had a chance to help Stani Michiels start coverage testing Phatch.

Antonio did a kick-ass keynote. He's posted the text and slides, but if you didn't see it, I recommend waiting for the video to get his inimitable delivery.

I booked my flight early, thinking that the presentations would be over by noon (for some reason), so I had to miss ones I really wanted to see. I'll plan better next time.

Overall, PyCon was the usual re-energizing experience, making me excited to continue contributing to the community, and seeing where things will go in the next year.


  • Sikuli is one of those tools that does the seeming impossible: automating GUI's directed by screenshots.
  • Python Docx looks like a useful tool for those of us that need to deal with Office documents.
  • A few people used Prezi to do unconventional presentations, and someone mentioned JessyInk also: a comparison.
  • In the future, will speakers pre-check that their good jokes fit into 140 characters so they can be effectively tweeted?

Couchio is hiring

Saturday 13 February 2010

Damien Katz has started Couchio to provide CouchDb hosting services. He's looking to hire an infrastructure engineer.

It should be an interesting gig for a few reasons. Start by reading Damien's Thoughts on an Open Source Company. I love the idealism of his approach. I'd quibble with whether someone needs to have contributed to open source: it's a great indicator, but doesn't seem like an absolute requirement to me. But Damien is a unique guy, with an often-unconventional outlook. See his CouchDB and Me presentation (complete with marker-on-legal-pad production values) for a history of the path he's taken so far.

Pretty much every step of the way Damien's done it wrong for some well-accepted value of "wrong". And so far it's worked out for him. I don't know his secret, but I wouldn't bet against him...


Wednesday 10 February 2010

AllRGB sets an unusual challenge: create a 4096×4096 image such that every possible RGB value is present once and only once. Most of the images look like the gray soup you'd imagine, but a few actually depict a real scene surprisingly well, and some are interesting as abstract art:

allRGB rendering of a natural sceneallRGB portrait of the Hilbert curve

Eric Burnett wrote about his allRGB Mandelbrot, which uses Hilbert curve techniques, as does Aldo Cortesi's portrait of the Hilbert curve. Conflict of interest disclosure: the gray background on my blog is a Hilbert curve. ☺

Of course, there's no practical purpose to these techniques, but they're interesting explorations of color spaces and image rendering.

A preventable Python packaging peeve

Tuesday 9 February 2010

Python packaging is a common theme on which to complain, and rightly so. It's no one's first love, so it tends not to get the devoted attention of say, Numpy. And it's a hard problem to solve well. So we have a mish-mash of tools that each do about 75% of the job.

But there's one small aspect of Python packaging that could easily be solved well if people just attended to it: Not enough Python projects clearly state what versions of Python they run on.

For example, suppose you are in the market for a mock object library for your tests. There's no shortage. Less than a minute at PyPI produces mock, MiniMock, mocktest, Mocky, pmock, mocker, mockito, and ludibrio. Some of those PyPI pages have extensive documentation. Not a single one explicitly mentions the versions of Python supported. And I don't mean 2.x vs. 3.x. I want to know if it will run on 2.4 or not. Ludibrio and Mocky offer a slight clue in that they are available for download as an egg, for 2.5 and 2.4 respectively. pMock mentions >= 2.3 support on the home page linked from the PyPI page.

On top of all the other well-known difficulties people have with Python packaging, at the very least, we should be able to manage this: clearly state what versions of Python you support. This is a simple three-step process:

  1. Decide what versions you want to support.
  2. Test your code on those versions.
  3. Add a sentence like this to your PyPI documentation: "SpockMocker runs on Python 2.5 and 2.6".

The Python community will thank you.

21st century life in transition

Monday 8 February 2010

Sitting at the breakfast table, my wife Susan was reading the paper, and when she got to the end of a story, dragged her finger down the paper to try to scroll the newspaper.

I've sat in a movie theater watching trailers, and glanced at the bottom of the screen to try to see the progress bar to see how much time was left in the short clip.

Max said when he's writing on paper with a pencil, and makes a mistake, his left hand twitches as if to hit cmd-Z.

Test classes, singular or plural?

Sunday 7 February 2010

A minor hiccup in writing unit tests is how to name the classes that contain them. The jUnit style of test class, which has been adopted by virtually everyone, including Python's unittest module, is that tests are methods of a class. The class is instantiated once for each test method, then three methods are called: setUp, the test method, and tearDown.

As a result, you end up with test classes that look like this:

# Tests for double_it, and no, no one would write them this way...
class DoubleItTests(unittest.TestCase):
    def test_ten(self):
        assert double_it(10) == 20
    def test_twenty(self):
        assert double_it(20) == 40

Here I've named the class DoubleItTests, plural. That's because I can see that it's a container for a number of tests. This feels right if you think about the class simply as a namespace for the test methods.

But what is instantiated from the class? Only single tests. In this case, the class will be instantiated twice, once to run test_ten, and once to run test_twenty. The class' name should really be the name of the objects. No one would name their user class Users under the theory that the class encompasses a number of users.

So the test class should really be called DoubleItTest, which I guess fits in with the unittest.TestCase base class it derives from. But somehow it just looks wrong.

This is reminiscent of the SQL table naming dilemma. Is it the CUSTOMER table, or the CUSTOMERS table? How you feel about it seems to come down to whether you think natively in SQL, or whether it's just a backing store for your ORM.

I'm getting used to the singular test class name, but it still doesn't come naturally, I have to remind myself to leave off those tempting plurals.

25 minutes is a bitch

Saturday 6 February 2010

This is the season for preparing talks for PyCon, which is less than two weeks away. I've not only been working on mine, but I organized rehearsals for the other Boston-area speakers, so I've been immersed in the process.

PyCon talks generally have half-hour slots, with five minutes at the end intended for questions from the audience, leaving only 25 minutes in which to get your message across. In some ways, 25 minutes is a long time to stand in front of a crowd of distracted strangers and try to explain something. If you've never done it before, you'll probably feel like you don't have enough to say.

But that isn't true, because if you've chosen a topic to propose for PyCon, and written a good enough proposal to get it accepted, you have identified a topic about which you are passionate. And expecting someone to talk about their passion in only 25 minutes is expecting a lot.

Thinking back over the eight talks I've seen in draft form this past month, they all have something in common: they aren't going to fit in their time slot. The speaker has over-stuffed the talk with all of the things that fascinate them about their chosen topic, and there just isn't enough time.

You have to make harsh cuts to the topic, you have to choose the one point you really need to make, and you need to avoid all the fascinating side alleys and back stories and witty asides you can. You need to make sure that you have a clear arc of a story to tell, and that arc has to fit in 25 minutes.

I use the word "story" intentionally, and it may seem out of place in a description of a programming talk. But no matter how dry you think your material is ("Here's how the __frabbitz__ methods work"), you need to give the listener a reason to care, and that reason will involve a story about a person like them. So you'll want the talk to include at least a little something like, "You're trying to write a program, your job will be much easier if you use __frabbitz__ like this...".

Once you have the arc of the story established, then you can add in asides and jokes and so on. It's important to be engaging and entertaining, but it can't be at the expense of your main points. You have to establish the skeleton of the talk (the main points and how you'll explain them) before you can embellish it with the extra stuff.

Unfortunately, 25 minutes means you have to abandon a lot of your cherished ideas on the cutting room floor. There will be fascinating points about which you are passionate, and you will not have time to mention them.

One important thing to remember: your listeners don't have to leave the room as expert as you are. It may be enough simply to convince them that this is a topic they care about, even if it means they have to go back later and really learn the details. If they go home knowing that __frabbitz__ is important, why it's important to them in particular and have some vague memory of some milestones along the journey, then they can fill in the details on their own, in their own learning style, later. You've done your job by planting those seeds.

For more on presentations in general, take a look at these presentation tips I wrote a few years back.

Custom letters 2009

Wednesday 3 February 2010

Custom Letters 2009 is an encyclopedic collection of hundreds of custom lettering projects done in the past year. The diversity is astounding, ranging from simple primitive art to elaborate hyper-calligraphic orgies. Some are witty, some are beautiful, some are illegible but leave a nice taste in your mouth. This one by Michiel Van der Born in particular caught my eye:

Typotalk poster by Michiel Van der Born

They say today they're picking a top ten, and Friday something called AlphaBattle begins. I don't know what it is, but it sounds interesting.

Lost cake

Tuesday 2 February 2010

Tonight is the first episode of the final season of Lost. Max has long been obsessed with the show, but the rest of us had never watched it. That is, until early December when we decided to power-chug through the existing five seasons on DVD, so we'd be ready for tonight. We finished watching the DVDs a few weeks ago, and are eager to see what's coming.

As is typical in our family, that excitement translates into cake:

LOST cake

It's a little hard to see the detail: we have a chunk of fuselage (cake), with a broken wing (chocolate bar) complete with turbine engine (Twinkie). Palm trees are Tootsie Rolls topped with gummy worms.

iPad ergonomics

Monday 1 February 2010

I watched the iPad announcement last week with interest. I'm not a gadget-hound, but Max and I were both home that day, so he gave me play-by-play commentary of the announcement. It's certainly an intriguing device with plenty of interesting facets to debate (open/closed, produce/create, and so on).

One thing I definitely don't get is the ergonomics of it. Look at this demonstration of editing a slide show on the iPad:

First of all, I don't understand his emphasis on the apparent miracle of coming up with ways to manipulate objects on the screen with touch. I thought we had all gotten used to the concept of touch and multi-touch. But that's not the main point. Watch it again, but don't look at the screen: look at his hands.

He looks uncomfortable. He's trying to hold the iPad in his left hand, and perform precise touching with his right. His non-touching fingers are being held stiffly up out of the way to avoid making an accidental multi-touch. He's got nowhere to rest his right hand. And when he has to touch with both hands, they keep crossing over each other like some kind of crazy-advanced piano sonata.

I can see using the iPad to watch stuff, or any task that doesn't require much input. But that demo showed me that it will be much too awkward to make the sort of gestures needed to do real work. People need to rest their hands on something. It's hard to hold your arm up without something to help carry the weight. Keyboards have palm rests, mice let your wrist sit on the desk. Palm-sized devices like the iPhone are light enough to hold while tapping with your thumbs. Maybe it would be OK while sitting in a chair with arm rests?

I'll be interested to see how people use the iPad. I could see propping it up in my lap with one hand and tapping for a while with the other, but long sessions, or two-handed use, just seem too unnatural.

« | » Main « | »