This is obviously just some guy's mostly throwaway code, but FWIW it's got the type of comments I don't find useful at all when reading code. I.e. comments that purely duplicate what can be trivially inferred from code:
# retrieve data
data = json.loads(request_until_succeed(url))
Not ambiguous, but better done by just naming the function in such a way that it's obvious that it's the thing retrieving the data. And:
num_processed = 0 # keep a count on how many we've processed
Is another example of a comment that doesn't compliment the code, but just distracts the reader from information they could equally, more accurately & more briefly have gotten from reading the corresponding code.
I think there's a place for the "# retrieve data" sort of comment. Suppose you're skimming rather than reading the code, either trying to get a high-level overview of what it does or looking for the particular bit of it where a particular thing happens. Then, sure, you could just read all the code; but most of us can skim-read a small quantity of text faster than a larger quantity of code. In a syntax-colouring editor it's easy to ignore everything but the comments, and if the top-level structure of what's happening is sketched in the comments that's helpful.
How helpful depends, of course, on the style of the code; in particular, it gets less helpful as the length of functions/methods goes down, and in the limit of "ravioli code" where everything is decomposed into 3-line methods whose main task is calling other 3-line methods, it doesn't help at all and the sort of comment you need to help with skimming is an overview of how the pieces fit together. At the other extreme, if you have the sort of 1000-line function that's quite common in e.g. numerical code, these structure-sketching comments can be invaluable.
Agreed; the original code was a part of a tutorial (http://minimaxir.com/2015/07/facebook-scraper/), hence the more liberal comments for clarity. (after my refactor, I'll remove a few)
