Combining ConfigParser and argparse with parse_known_args()

Edited to add: The best place to discuss this topic is on my original answer on StackOverflow.

I'm a fan of both the ConfigParser and argparse modules in my Python scripts and I've always thought it would be great to have a way to combine them. In other words allow the user of a script to provide a command line option that specified a configuration file that specified defaults for the command line options.

Recently I discovered the parse_known_args() method, which allows one to do just that.

Here's the script p.py that demonstrates this:


Here's a configuration file and a demonstration of how it works:


So this is what I was looking for, the caller can specify a configuration file with defaults, but override those defaults with more command line options.

There's only one problem, the help option only shows the configuration file option:


That's because the '-h' is processed by the parse_known_args() instead of the final parse_args(). The way to fix this is to create two ArgumentParsers and use the add_help parameter when creating first to suppress it from parsing -h:


Now help works like you would expect:

Using 'git stash' as a Todo list

I noticed I've been using 'git stash' as a todo list for simple development tasks. The scenario is that I'm doing some coding and run across a minor bug that I don't want to fix right at that moment, I write myself a todo as a comment right at the relevant piece of code, e.g.:

# The following function should check the argument and make sure
# it is an integer greater than zero otherwise it throws a really weird error:
#  ...some example of error...

And then save it to the stash with with a descriptive message (use 'git stash save --patch' if I have other stuff in my working tree):

git stash save "foo.c TODO: check argument is greater than zero"

Then later I use 'git stash pop' to bring my comments back into my working tree, make the fix and commit it. (You can name the TODO stash if you've save other things to the stash after the Todo.)

This is a reverse of the "interrupted workflow" example in the git-stash man page. Instead of interrupting my work for the bug, I'm pushing the bug into the stash so it doesn't interrupt me.

The nice thing is the comment is right in the code where it is relevant. Plus by using the string "TODO" in the message, I can quickly view any stashed todos:

% git stash list | grep -i todo
stash@{0}: On develop: foo.c TODO: check argument is greater than zero

Obviously this doesn't replace a real bug tracking system, but it works well for fixes I want to get to "soon" without interrupting my current flow. If it turns out I can't get to it soon, it's easily committed so I don't lose it.

Update 11/29: Someone on HN suggested branches were a better way to do this. I played with it briefly and worked out the following script to use branches (this is a quick hack and missing a lot of error checking, don't even thing about trying to use it): (Update: doesn't quite work as written, you need to use "git symbolic-ref HEAD" as described here.)

#!/bin/sh
msg=$1;shift
# Kudos: http://stackoverflow.com/questions/1593051/how-to-programmatically-determine-the-current-checked-out-git-branch
branch=`git name-rev --name-only HEAD` 
git checkout -b $msg
git add -p
git commit -m "$msg"
git checkout $branch

So this approach would work, and I kinda like the idea, but frankly by the time you polish this script enough to make it robust, you may as well just use a real issue tracker.