Every time I see people using printf to generate structured data formats, a part of me dies inside.

Here's how I would do it, using libgit2 and proper JSON output: https://gist.github.com/m1el/42472327b4be382b02eb

Every time I see this pattern, a part of me dies inside.

    collection = []
    for i in data:
        collection.append(fn(i))

Why not just

    [fn(i) for i in data] ?

You are right, list comprehension are cool and I often use them.

However, in this particular case, IMO, it would make things worse because I would have to write a multi-line list comprehension. Multi-line list comprehensions have bad readability. The object literal is too big to be included in list comprehension.

I could move commit->object conversion to a function, but then I would have used map. And it would have created one more indirection.

The current state is my deliberate choice.

If we are nitpicking then why not

    map(fn, data)

?

List comprehensions are more direct, support more than just a function call, and in py3 map returns an iterable instead of a list (granted, easily solvable by list(map()) but it's an extra concern)

List comprehensions are the very recommended strategy for constructing python lists, not to mention they're simply a fantastic language feature. Very direct, readable, and hard to get wrong.

Python loses out a lot on it's functional sorts of functions (filter, map) because you can't use method chaining on a list for them, imo

First example is way, WAY, more readable. Honestly, if I didn't read the first one I would probably not have figured out what the other one does without research.

> What if there's a double quote in a commit message?

This is what I want to know too. Unless I'm missing something, it doesn't do any escaping. The last time I did something like this, I used %n and %x00 to delimit the output of git log, and converted it to a JavaScript object on the JavaScript side. Git log isn't smart enough to write JSON by itself.

Agreed on better output to text, then process, but I'd suggest the record & group separators... It always surprises me when people use more exotic characters for something that's been defined forever (practically) in computer terms for this purpose.

http://www.theasciicode.com.ar/ascii-control-characters/reco...

I did something very similar for work last summer and we basically realized the same thing - null-delimited fields seemed like the only way to really be safe.

Mercurial has a properly designed extensible generic template system for that built-in.

  hg log -T json
  hg log -T xml
  hg status -T json
  hg tags -T json
  ...

Only somewhat related, the really neat tool code-maat[0] can do a lot with your commit data, but it uses plain CSV. It provides a bunch of canned reports you can run on your repo as well.

[0] https://github.com/adamtornhill/code-maat