Notes on “Expert Python Programming”

February 2, 2009

I bulled through “Expert Python Programming” by Tarek Ziadé this weekend. Mostly I hoped for some tips that might save some time and effort for my 2125 project. Here are some highlights.

 

  • Use generators, itertools and coroutines where appropriate.
  • Check out the Python Decorator Library.
  • There’s a paper about Python’s Method Resolution Order.
  • There’s a How-To Guide for Descriptors. Python getter/setters are called descriptors.
  • There’s an introduction to metaprogramming in Python.
  • Use PyLint to check Python style and CloneDigger to detect duplicate code.
  • I’ll want to create a PEP 301 Trove classification for PyVCAL based on the official list of classifiers.
  • Python build managers are zc.buildout, Paver, and AutomateIt. I don’t like what I’ve seen of zc.buildout so I’ll have to check out the others.
  • Buildbot automates compiles and tests and should be plugged in as a post-commit hook in the version control repository.
  • Trac has plugins for different version control systems. I need to look into this.
  • Seven writing rules for technical documentation:
    • First write ideas, then focus on style
    • Tailor to the reader
    • Keep it simple
    • Introduce one concept at a time
    • Use realistic code examples
    • Keep it light, but make sure the documentation is sufficient
    • Use templates
  • Use Paster for documentation templates
  • Sphinx helps to make documentation.
  • “Tests are the best place for a developer to learn how software works. They are the use cases the code was primarily created for. Reading them provides a quick and deep insight into how the code works. Sometimes, an example is worth a thousand words. The fact that these tests are always up to date with the codebase makes them the best developer documentation a piece of software can have. Tests don’t go stale in the same way documentation does, otherwise they would fail.”

    Whoa. This suggests two studies: Do developers use tests as documentation to understand a codebase? (intuition: No.) If we encourage them to use tests as documentation, do they understand the codebase faster than developers just using traditional documentation? (intuition: No.) Finally: Real projects often have tests that fail and are ignored. Tests do go stale.

  • There’s a Python Testing Tools Taxonomy.
  • Minimock is a good mocking library.
  • PyMetrics implements some metrics on codebases.
  • Eventlet and Twisted are cool concurrent network programming libraries.
  • PyDispatch is a multi-consumer multi-producer dispatch mechanism and might be a good way of implementing the Observer pattern.
  • A little bit of metaprogramming makes the Visitor pattern better. One example is in the compiler.visitor module.
Advertisements

3 Responses to “Notes on “Expert Python Programming””

  1. Rory Says:

    Re: unit tests as documentation. This was one that I put in the thesis hat early last semester. I’m pretty sure you shot it down for some reason or other, but since you bring it up again, maybe it’s got legs. However, you’ll need some metric to measure ‘understanding’, and then apply it to documented code, and undocumented but tested code. Also, need some way to normalize the amount of information that the docs and the tests convey. Ie. a suite of unit tests might provide less information than a page of comments before every method definition.

  2. Rory Says:

    This idea came to me while learning the jMonkeyEngine.
    http://www.jmonkeyengine.com/

  3. Edward og Says:

    It’s actually pretty often that I find myself reading tests to understand the intended use of code in lieu of documentation.

    (but then I realize that the use case i’d end up sticking in the comment looks a lot like the unit test, except that the unit test’s code actually runs, and ends up being much more resistant to stagnation for that reason.)


Comments are closed.

%d bloggers like this: