PEP 8: clarify and/or remove "72 character for flowing text" recommendation

[asottile]

This was added in 7112960 by @gvanrossum

In its current state it reads:

For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.
...
For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length ..., provided that comments and docstrings are still wrapped at 72 characters.
...
The Python standard library is conservative and requires limiting lines to 79 characters (and docstrings/comments to 72).

The 72 is pervasive throughout the text but doesn't seem to have any rationale behind it.

For instance, this dictates the first line be rewritten but not the second (despite being the same length)

-# this is a very long comment talking about the next line directly below this
+# this is a very long comment talking about the next line directly
+# below this
 this = a + very + very + very + very + very + very + long + line + '79 chars.'

as far as I can tell the only place this would/could make a difference is when accessing and printing __doc__. Though inspect.getdoc does the correct thing (removing linebreaks, dedenting, etc.).

It seems arbitrary to me, but I might be overlooking something 😆

Ideally this issue results in:

• some text clarifying the rationale for this or
• the 72 character recommendation removed

The reason I bring this up is the current (unreleased) master of pycodestyle has added a lint rule for this bit of pep8 and imposing that will likely cause (nearly) every repository in existence to fail on this rule. PyCQA/pycodestyle#828 (comment)

[asottile]

alternatively: maybe this should move to PEP 257?

[gvanrossum]

Please, this isn't going to change. 72 is an ancient convention (check out "FORTRAN column 72"), but one that nicely captures readability concerns -- while the occasional line of code extending to 100+ characters isn't too bad, a block of text at 100 characters wide (or 92, if you subtract 2 indents) is hard to read.

[asottile]

I can't find anything about "FORTRAN column 72" -- could you link some supporting material?

All I'd like in PEP8 is some rationalization for the "subtract 2 indents" since it's new to me and could strengthen the case of that

[asottile]

Some stats on python/cpython showing this isn't followed:

$ python pycodestyle/pycodestyle.py Lib/ --select=W505 --max-doc-length=79 | wc -l
1254
$ python pycodestyle/pycodestyle.py Lib/ --select=W505 --max-doc-length=72 | wc -l
11898
$ python pycodestyle/pycodestyle.py Lib/ --select=W505 --max-doc-length=4 | wc -l
89735

~1.4% of cpython docstrings exceed 79
~13.3% of cpython docstrings exceed 72

[gvanrossum]

http://www.gnu.org/software/emacs/manual/html_node/emacs/Fortran-Columns.html

The two indents are just what you get for a docstring in a method.

Showing the rule is being violated does not mean the rule is wrong.

If pycodestyle wants to annoy people, this is a good way to do it.

[asottile]

oh! so the indent and """ aren't counted against the 72 characters? so in reality it's still "doesn't exceed 80 characters"

if that's the case I think pycodestyle misinterpreted PEP8 and the language should be clarified

[asottile]

                                                                   72 v   79 v
                                                                      |      |
def f():
    """is this ok by pep8.....................................................

    or is this the max................................................
    """

[gvanrossum]

No, the intention is 72 chars including indent, so net text width is 64.

Also, please stop.