我最近开始认为遵循PEP 8是一个好主意。我让我的编辑器显示80列标记，现在我正在尝试换行以适应它。我的问题是这个。在PEP 8中它说：
将所有行限制为最多79个字符。
说得通。
[...]对于流动的长文本块（文档字符串或注释），建议将长度限制为72个字符。
为什么72？为什么79不适用于文档字符串或注释？
我最近开始认为遵循PEP 8是一个好主意。我让我的编辑器显示80列标记，现在我正在尝试换行以适应它。我的问题是这个。在PEP 8中它说：
将所有行限制为最多79个字符。
说得通。
[...]对于流动的长文本块（文档字符串或注释），建议将长度限制为72个字符。
为什么72？为什么79不适用于文档字符串或注释？
我相信这是文本文档的遗留问题：
在打字机时代结束时，大多数设计都面向72 CPL，从每英寸12个字符的间距，乘以6 英寸（参见例如IBM Selectric）。这将确保至少1 每个保证金英寸，美国政府当时有 标准化为8 1/2×11“纸张。
许多纯文本文档仍然符合传统的72 CPL。
我认为这就像文档字符串经常在代码之外的上下文中使用一样，因此符合大多数纯文本文档用来尝试并保持尽可能一致的样式是有意义的。例如，文本 man 页面通常包装为72个字符。通过将文档字符串限制为72个字符，输出 help() 反映了这个。
关于程序员的这个问题 也可能是相关的。
文档字符串通常使用其功能缩进，并以三引号开头和结尾：
def foo(bar, baz):
"""Frobnicate the foobars into baz
Parameters are ham and spammed.
"""
这是79 - 4 - 3 =剩下72个字符。
行应该是79个字符的原因是它们可以适合80字符宽的终端（显然它们仍然存在）。在docstring上使用72个字符的原因是，这意味着您在两侧都有相等的填充（毕竟文档字符串是缩进的）并且仍然适合80个字符的宽度。