哪些 PEP 是必读的？答案

【问题标题】：Which PEP's are must reads?哪些 PEP 是必读的？
【发布时间】：2010-11-25 20:11:53
【问题描述】：

我是一个相当强大的 Python 编码员，但我的风格太多有点随意，而且我确信对于许多问题有更多的 Pythonic 解决方案，而不是我想出的解决方案。对于精通 Python 的人来说，哪些 PEP 是必不可少的？

【问题讨论】：

python.org/dev/peps
应该是社区维基

标签： python pep

【解决方案1】：

绝对是PEP 8，Python 风格指南。

【讨论】：

阅读时使用大量的常识。完全忽略关于“79 个字符”的部分；它已被大脑损坏并导致丑陋、难以阅读的代码，而对现实世界没有任何好处（这是在 2001 年编写的，当时健全的开发系统还不是 80x25）。 “矩形”示例的可怕之处非常清楚地表明了这个问题。
尽管我的屏幕是 22"，但我所有的编辑器/终端窗口都固定为 80 个字符，我尝试相应地编写代码。（但是，正如 Terry Pratchett 所说，规则是为了让你思考在打破它们之前。）
PEP 8 最初是在 2001 年编写的，但此后多次更新。如果 80 列不再重要，那么它可能已被删除。 hg.python.org/peps/log/5dceea0aaa49/pep-0008.txt
超过 80 个字符的行通常本身就很难看。不过，@Gleen 并不是对你的批评，因为它经常被需要，而且 实用性胜过纯洁性 :)
我碰巧读到这种方式晚了——但假设其他人也会这样； Pep 3099 解决了 80 个字符的问题，强调它不会消失（至少作为建议）；在编码风格下，在底部附近向下看； python.org/dev/peps/pep-3099

【解决方案2】：

尽管 Python 非常直观，但很多人并不理解他的哲学。

Pep 20: Python之禅

美胜于丑。

显式优于隐式。

简单胜于复杂。

复杂胜于复杂。

平面优于嵌套。

稀疏优于密集。

可读性很重要。

特殊情况不足以打破规则。

虽然实用胜过纯粹。

错误绝不应该悄无声息地过去。

除非明确静音。

面对模棱两可，拒绝猜测的诱惑。

应该有一种——最好只有一种——明显的方法它。

虽然这种方式一开始可能并不明显，除非您是荷兰人。

现在总比没有好。

虽然从来没有比现在更好正确。

如果实现难以解释，那就是个坏主意。

如果实现易于解释，那可能是个好主意。

命名空间是一个非常棒的想法——让我们做更多这样的事情！

【讨论】：

【解决方案3】：

还有 pep 0257 文档字符串约定

【讨论】：

【解决方案4】：

它现在是回顾性的，但仍然很有趣：我认为 Things that will Not Change in Python 3000 是一本不错的读物，其中有很多链接指向决策之前的讨论。

【讨论】：

【解决方案5】：

我发现阅读被拒绝的那些可以很好地了解什么是 Pythonic，什么不是。这是不久前的事情，所以我没有任何具体的例子。

【讨论】：

【解决方案6】：

这是 PEP 的索引 - http://www.python.org/dev/peps/

当有人对某个主题有疑问时，他们可以搜索该主题

【讨论】：

【解决方案7】：

我还推荐 PEP 8 和 257。我知道这与最初的问题略有不同，但我想指出 PyCharm（在我看来可能是最好的 Python IDE）会自动检查你是否是遵循一些最重要的 PEP 8 指南，以防万一有人感兴趣...

【讨论】：