Oops, yes, I don't think I can change that habbit ;)

Merged. Mail sent to google group.

Looks good! One last minor niggle before you merge: we use "double-quoted"
strings everywhere in the translator. It'd be good not to start mixing styles.

I uploaded a new patch set.

Sure, that'll make the code cleaner, too. We actually had bugs in the past where
a typo in a local variable name was missed because a global variable of the same
name was introduced in the __main__ block.

(Regarding Python 2.6, I missed the from __future__ import at the top in my
small test.)

It runs fine here. However testing with the test script would be easier 
if the code under __name__ == '__main__' would be encapsulated in a 
function (e.g. main()). Can I add that?

Thanks!

Have you run the test script? I don't think this code will run on Python 2.6.

I incorporated your comments and uploaded a new patch set.

Can we use optparse instead? There's other options I'd like to add eventually;
at least the stuff that is currently set via constants in translate.py.

Also, I'd prefer to see this functionality moved to a function, and to also have
a warning message printed when the force flag is set. Finally, warning and error
messages should be printed to stderr, not stdout. (We're not consistent in that
in the translator, but we've been enforcing this for a while in the search code.)

Rietveld issue created: http://codereview.appspot.com/6133062/

From issue329:

Malte: I think we really need a big fat warning when Python 2.6 is used. Actually, I
think the planner should even refuse to run unless it is passed a special option
("--force" or whatever). ("Errors should never pass silently, unless explicitly
silenced", and major performance degradation definitely is an error in our field.)