Real Ultimate Programming

The Home for People Who Like to Flip Out and Write Code

Notes From PyATL 2009-05-14

What follows is essentially a stream-of-consciousness dump from the PyAtl meeting tonight.

Python Atlanta Meetup 2009-05-14


They’re recruiting people to do A/V work during PyCon here in Atlanta next year. Does this mean I get in to the con for free?

Hot Topics
  1. Community - you can get a lot of benefit from small-scale con-style stuff; look for the upcoming article about PyOhio in Python Magazine
  2. Distutils - Interesting things on the distutils mailing list
  3. IronPython - lots of buzz, but it’s not relevant to me right now
Testing with Nose

Alfredo Deza presenting.

Talking about testing Supay (a daemon module; named after an Incan demon god). Why another daemon module?

  • PEP 3143
  • It’s really a service, not just a daemon
  • At least it’s not a new web framework
  • Start, Stop, Status
  • Spawn children

Originally testing was done in Pythoscope. Easy to get started. Moved on to nose. Had problems because things under test were backgrounding, etc. People on the testing in Python mailing list advised him to test smaller chunks. coverage does testing coverage reporting for nose. coverage gives you really specific (package- specific, etc.) statistics.

The cool thing about nose is that it autodetects your tests.

One early gotcha: You have to invoke nose using nosetests. ed. I might as well alias nosetests to nosetests -v --cover-package=$package_name. Simply add --with-coverage to get the coverage report.

Cool, Pythoscope generates test stubs for you. I need me some of this.


There was some A/V stuff going on here, so they took this opportunity to hand out books for review. I scored Expert Python Programming.

Choosing a Testing Framework

Brandon Rhodes presenting.


At first, he thought testing would help most by helping to get it right at first. Once he started testing, he discovered that it helped most with finding regressions. Much like undo, now he can’t imagine getting by without it. One thing to note: installed Python packages rarely ship with tests, so if you want to muck around in them, you typically need to download the tarball yourself.

What does Python testing look like without a framework?


Uses setuptools, so you can just use the built-in test command. You can use an additional_tests function to build a test suite for setuptools. setuptools will not autodetect doctest tests. All in all, this is a pretty well-behaved module.

Sidenote: virtualenv - creates local, tiny Python install that you can use to avoid system-wide changes. I’ve seen it mentioned before, but this is the first time I’ve seen it in action; this could be seriously cool.


Has a README.unittests (referenced from README) that tells you exactly how to do things. There is a lot of work to manually keep track of the tests in modules; obviously, this is begging for someone to forget to add a test to the suite.


The tests here are pretty idiosyncratic (each test defines a complete web app and puts it through its paces). It uses part of zc.testrunner.

Three testing frameworks

Python testing frameworks:

Questions you should ask:

  • How are tests discovered?
  • How can tests be filtered and selected?
  • How fancy are tests when reported?

One benefit of testing frameworks is that it makes the testing in your project look like the testing in other projects that use the same testing framework.


Not really covered beyond what we saw with Grok.


Finds tests based on a naming convention; this is not configurable. Tests are just functions; you don’t need a class w/ test methods. You can tag tests any way you want. By default only outputs print statements if it fails. Has distributed tests and multiplatform, but the documentation is a bit sparse. Uses a module to turn on autodetection for doctest tests.


Finds tests based on a naming convention; this is configurable. Tests are just functions; you don’t need a class w/ test methods. You can tag tests any way you want. Has more extensive documentation and seems to have momentum.

It is probably feasible to write your tests so both py.test and nose can find and run them.

Selenium Demo (lightning talk)

Brandon Rhodes presenting.

Not a lot new to me; already used Selenium at work. The Python client seems to be doing a pretty good job of being Pythonic; the tests use unittest, etc. The basic commands seem pretty similar to the Java client I’ve used before.

Google Code and Hg (lightning talk)

Alfredo Deza presenting.

Brief compare/contrast between hg and svn. I’m already familiar with both so I won’t recap this part of the presentation.

Traditionally, svn has been the standard for Google Code. They’re giving invites to anyone attending the Google IO Conference (next week?). They’re also accepting applications here; this is for old projects and they will move it over to keep the history. Not all features are available on the Mercurial version yet, e.g., code browsing.

Coolest feature: hg serve. It sets up a web interface to your entire repo on localhost:8000. It’s pretty sophisticated, and allows you to push and pull from it.

And that concluded the evening.

Back to flipping out…