Python Development Tools of the Trade

Last week, Bruce Momjian commented that pgindent is one of the reasons for the clarity of the PostgreSQL source code. Today, Andrew Dunstan remarked on “how cleanly it compiles” and no doubt this is due in great part to the buildfarm. So I thought I’d reflect on the tools I’ve been using to ensure the clarity and quality of the Pyrseas code.

Editors

Early in my career, I had a brief encounter with TECO. I also encountered Brief (but for a longer time). Perhaps that explains why, after many years of using vi and vim, in the past few years I’ve gone back to my roots, if you will, and I’m using Emacs for programming.

Some of the Emacs features I find helpful or convenient in developing quality code include (in no particular order):

  • Syntax highlighting: Whether it’s Python, ReStructured Text for the Sphinx documentation, or C in the PostgreSQL code, syntax coloring is nearly always on, by default based on the filename extension.
  • Parentheses matching: Not only for parens, but also for brackets and braces (particularly helpful when creating or editing Python dicts and JSON/YAML maps).
  • which-func-mode: Being able to tell which function/method you’re editing, on the status line, when the head of the function may not be in view.
  • Git branch: Shows in what branch you’re editing, again on the status line. For Subversion, it shows SVN-nnn where nnn is the revision number that last affected the current file.

Unit Testing

I have used the Python unittest testing framework, almost religiously, to develop tests before writing code. I initially also looked at py.test and briefly at nose, but decided the standard library module was good enough. The unit tests have been invaluable when adding features or refactoring code.

Version Control

Git was my choice for a VCS. Two Git features are worth mentioning. One is the change coloring in git diff, but also the context information, e.g., it shows the Python class in which the difference occurs. Second is the ability to stash away work in progress.

Code Quality

I’ve been using pep8 to ensure the Pyrseas code follows as much as possible the Python Style Guide. This is the tool closest to pgindent, but it doesn’t reformat the code.

Lastly, before making the code available publicly, I ran pylint against it. Then I edited it accordingly to improve readability and to eliminate some warning categories.

About these ads

2 thoughts on “Python Development Tools of the Trade”

  1. You’re free to use whatever VCS helps you work well, but I wonder if you tried Bazaar before making that choice? I ask because the two features you mention – colour diff output and shelving work in progress – have long been Bazaar features, even (I think) before Git.

    I agree that shelving changes in progress is a remarkable feature; it’s one of the main reasons I chose Bazaar.

    1. Hi Ben,

      I’ve used Bazaar but only as a “browser,” i.e., I installed it to access some other projects’ source code, but only skimmed through its features. The other DVCS I experimented with more extensively was Mercurial, but I became biased towards Git after watching a talk by Linus Torvalds and hearing that PostgreSQL development was switching from CVS to Git. I’ve also used Subversion for quite a while and going back memory lane, I recall using SCCS on SunOS, MMS on VAX/VMS and the precursor to Perforce.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s