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.

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.

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.

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.

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.

As is typical in our family, that excitement translates into 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.

Join us if you want to see some great Python talks. RSVP here.

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.

I added a function to coverage.py that is suitable for executing on startup. It examines the environment to determine whether to start measuring coverage. (This code isn't released yet, but if you want to try it, it's on the trunk at bitbucket.)

Perl has a command line switch (-M) for this, as does Ruby (-r), but Python doesn't. I came up with two ways to do it for Python, both depending on the site module which is imported automatically on startup.

The first way is to create a sitecustomize.py file on the path somewhere. This module will be imported automatically by site.py. Any lines you add to that file are executed when Python starts:

import coverage
coverage.process_startup()

This is simple, but editing an existing sitecustomize.py could be awkward, and you may not even have permissions to do it.

The second way is to create a .pth file with an executable line. Usually lines in .pth files are directory names, but if the line starts with "import ", it is executed (what a hack!), so you can create a .pth file like this:

import coverage; coverage.process_startup()

This has the advantage that you can create a new file without worrying about touching existing files, all .pth files will be examined and interpreted. Unfortunately, you might have to give the file a strange name, since they are executed alphabetically, and a package you need may only be available after its .pth file has been seen. In my case, I named my .pth file zzz_coverage_process_start.pth to be sure it ran after coverage was added to the path.

Neither of these feels clean or elegant. I'm wondering if there are better techniques I'm overlooking? Python has a clean way to register functions to be called at process exit (atexit), which has been designed so that multiple authors of exit functions don't need to cooperate to avoid interfering with each other. It'd be nice to have a similar facility for startup functions.

Full details and RSVP: PyCon on the Charles, part 1. There may even be snacks.

Boston has six speakers this year, so part 2 will be on February 3: PyCon on the Charles, part 2.