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.
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.
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.
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.
Here's how I would do it, using libgit2 and proper JSON output: https://gist.github.com/m1el/42472327b4be382b02eb