This article makes no mention of flake8: http://flake8.readthedocs.org/en/2.0/

which is the up-to-date python style checker built on top of pep8 and pyflakes.

Some of the stuff in PEP8 is pretty subjective. What's the state of play for fixing that with an automated tool? Does is spit out advisories, or has some effort been put into the Small Matter Of Programming of interpreting the intent of code? I presume nothing can be done about

    x += 1    # increment x

You can pass flags to pep8 to ignore specific errors. For our project, we have:

--max-line-lenght=120 --ignore=E128

Came to say the same. A call to flake8 is a very useful step in most of my Git pre-committ hooks.

"Limits all the lines to a maximum of 79 characters" - what am I, a farmer with an 800x600 VGA CRT?

* Reading a side-by-side diff * Split-screen editor with multiple columns * Editor side-by-side with documentation

Long lines are also bad for readability – too much happening in a single line. If you have a very long line, either your names are too verbose, you need to break up your logic into easier to follow steps, or you need to write a function definition and give the logic a name.

79 character lines are arbitrary, but a short line length limit follows directly from the Zen of Python.

PEP 8 goes on to give the rational: "Limiting the required editor window width makes it possible to have several files open side-by-side, and works well when using code review tools that present the two versions in adjacent columns."

It also says that if your team can agree on a longer length, it's okay to increase it.

No, but you might be someone who has two windows of code open at once, or code & a spec sheet (or algorithm description, or help/man page) open side-by-side.

(That said, I prefer 100 columns: two 100 column files fit perfectly next to each other on my screen.)

I had a professor set the line limit at 109 for our assignments, specifically because that's what would fit side-by-side on his monitor.

Why would a farmer be coding his python on an old 800x600 VGA CRT?

I can vouch for Pylint, it's very good at finding errors in your code.

Now, all tools have some "pedantic" error reporting, like "function is too complex", thanks, who decided function complexity is me, not some arbitrary determination that functions longer than N lines are "too complex"