> 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.
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.
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.
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.
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.
The Map one exactly describe what it does. it 'maps' the data. Which means it describes it in the way function fn is telling it. Which is really easy to read if you understand english...
>> You need to know the syntax of "[...]" to know what it does.
Anyone with even a basic understanding of python (the language of the examples we've been discussing here) should know this syntax. If they didn't I'd be worried.
I never talked about fn(i) for i in data.
That's pythonic as somebody explain but the map one is the most readable and appears in more and more languages, even Java.
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
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.
16 comments
[ 5.6 ms ] story [ 52.8 ms ] threadThis 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.
http://www.theasciicode.com.ar/ascii-control-characters/reco...
[0] https://github.com/adamtornhill/code-maat
Here's how I would do it, using libgit2 and proper JSON output: https://gist.github.com/m1el/42472327b4be382b02eb
The Map one exactly describe what it does. it 'maps' the data. Which means it describes it in the way function fn is telling it. Which is really easy to read if you understand english...
Maybe I missed something, but how does this
> [fn(i) for i in data]
read easier if you know english? You need to know the syntax of "[...]" to know what it does.
The top/first example, however, actually reads like english.
If you knew Python you'd know exactly what that means. But zokier is right, a map is probably a better choice here.
Anyone with even a basic understanding of python (the language of the examples we've been discussing here) should know this syntax. If they didn't I'd be worried.
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
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.