目录缩进制表符还是空格？行的 长度空行源文件编码导入无法忍受的其它建议注释块行内注释文档字符串根本原则描述：命名风格规定：命名约定
介绍
本文档所提供的编码规范，适用于主要的Python发行版中组成标准库的Python代码。请参阅PEP关于Python的C实现的C编码风格指南的描述[1]。本文档和PEP（文档字符串规范）改编自Guido的《PythonStylGuid》一文，用Barry的风格指南[2]做一些补充。这篇风格指南随着时间的推移而逐渐演变，随着语言本身的变化，过去的约定已经过时了并确定了更多新的约定。许多项目都有自己的编码风格指南。如果有任何冲突，优先使用该项目特定的指南。
令人讨厌的小人物身上愚蠢的一致性
Guido的一个重要的见解是，代码阅读的次数比编写的次数多。这里提供的指南旨在提高代码的可读性，并使各种不同的Python代码一致。如PEP20所说，“易读性非常重要”。风格指南是关于一致性的。与本风格指南一致很重要。项目中的一致性更重要。一个模块或功能中的一致性最重要。最重要的是：知道何时会不一致——有时风格指南就不适用了。怀疑时，作出你 的判断。看看其他的例子，并决定什么是 的。不要犹豫，尽管发问！特别地：不要只为遵从这个PEP而打破向后兼容性！忽视既定指南的一些其他的好理由：1、当应用指南会降低代码的可读性，即使对于那些习惯遵照这个PEP来阅读代码的人来说。2、与周围的代码保持一致也会破坏它（可能是历史原因）——虽然这也是收拾别人烂摊子的好机会（在真正的XP风格中）。3、因为问题代码先于指南，又没有其它的修改理由。4、代码需要兼容老版本，本风格指南不建议使用的Python特性。
代码布局
缩进
每级缩进使用4个空格。连续行应该对齐折叠元素，无论是垂直的Python的隐式行连接圆括号内的，中括号内的，大括号内的，还是使用悬挂缩进[5]。使用悬挂缩进应注意以下几点；
行没有参数并且使用更多的缩进来区别它本身和连续行。
风格良好：
风格不良：
对于连续行，4个空格规则是可选的。可选的：
if语句条件块足够长时需要编写多行，值得注意的是两个字符组成的关键字（例如if），加上一个空格，加上开括号为多行条件的后续行创建一个4个空格的缩进。这可以给嵌入if内的缩进语句产生视觉冲突，这也自然被缩进4个空格。这个PEP没有明确如何（是否）进一步区分条件行和if语句内的嵌入行。这种情况下，可以接受的选项包括，但不仅限于：
多行结构中的结束花括号/中括号/圆括号是 一行的 个非空白字符，如：
或者是 一行的 个字符，如：
制表符还是空格？
空格是缩进方法的 。制表符仅用于与已经用制表符做缩进的代码保持一致。Python3不允许混用制表符和空格来缩进。Python2代码混用制表符和空格缩进，将被转化为只使用空格。调用Python2命令行解释器时使用-t选项，可对代码中非法混用制表符和空格发出警告。当使用-tt选项，警告将变成错误。这些选项是高度推荐的！
行的 长度
限制所有行最多79个字符。下垂的长块结构限制为更少的文本（文档字符串或注释），行的长度应该限制在72个字符。限制编辑器窗口宽度使得并排打开多个文件成为可能，并且使用代码审查工具显示相邻列的两个版本工作正常。绝大多数工具的默认折叠会破坏代码的可视化结构，使其更难以理解。编辑器中的窗口宽度设置为80个字符。即使该工具将在 一列中标记字形。一些基于网络的工具可能不会提供动态的自动换行。有些团队强烈喜欢较长的行长度。对于代码维护完全或主要由一个团队的，可以在这个问题上达成协议，象征性的将行长度从80个字符增加到个字符（有效地增加 长度到99个字符）也是可以的，提供注释和文档字符串仍是72个字符。Python标准库采取保守做法，要求行限制到79个字符（文档字符串/注释到72个字符）。折叠长行的 方法是在小括号，中括号，大括号中使用Python隐式换行。长行可以在表达式外面使用小括号来变成多行。连续行使用反斜杠更好。反斜杠有时可能仍然是合适的。例如，长的多行的with语句不能用隐式续行，可以用反斜杠：
（为进一步思考With语句的多行缩进，见前面多行if语句的讨论。）
另一个这样的例子是assrt语句。确保适当的连续行缩进。
换行应该在二元操作符的前面还是后面？
过去二十年我们都是推荐放在二元操作符的后面。但是这种做法会以两种方式 可读性：多个二元操作符在屏幕上不在一列，另外如果你想知道对一个被操作的对象做了什么操作，需要向上找一行。这导致你的眼睛不得不上下往返很多次才能搞清楚哪个数字是被加的，哪个数字是被减的：
为了解决可读性问题，数学家和印刷业者通常是在二元操作符之前换行的。DonaldKnuth在他的《计算机与排版》系列文章中解释了这个传统规则：“虽然写在一段话中的公式经常在二元操作符的后面换行，但是单独展示的公式通常是在二元操作符的前面换行。”
出于遵循数学传统，所以我们这样写这段代码将更加可读：
空行
函数和类的定义之间有两行空行。类内部的函数定义之间有一行空行。额外的空行用来（谨慎地）分离相关的功能组。相关的行（例如：一组虚拟实现）之间不使用空行。在函数中谨慎地使用空行来表示逻辑部分。Python接受control-L（即^L）换页符作为空白符；许多工具把这些字符作为分页符，所以你可以使用它们为文件中的相关部分分页。注意，一些编辑器和基于Wb的代码查看器可能不能识别control-L是换页，将显示另外的字形。
源文件编码
Python核心发布中的代码应该始终使用UTF-8（或Python2中用ASCII）。文件使用ASCII（Python2中）或UTF-8（Python3中）不应有编码声明。在标准库中，非默认编码仅用于测试目的或注释或文档字符串需要提及包含非ASCII字符的作者名；否则，使用\x，\u，\U，或\N是字符串中包含非ASCII数据的首先方式。Python3.0及以上版本，为标准库（参见PEP）规定以下策略：Python标准库中的所有标识符必须使用ASCII标识符，在可行的地方使用英文单词（在很多例子中，使用非英文的缩写和专业术语）。另外，字符串和注释必须用ASCII。仅有的例外是（a）测试非ASCII的特点，（b）测试作者名。不是基于拉丁字母表的作者名必须提供一个他们名字的拉丁字母表的音译。开源项目面向全球，鼓励采用统一策略。
导入
导入通常是单独一行，例如：风格良好：
风格不良：
这样也是可以的：
导入常常位于文件顶部，在模块注释和字符串文档之后，在模块的全局变量和常量之前。导入应该按照以下顺序分组：1.标准库导入2.相关的第三方导入3.特定的本地应用/库导入在每个导入组之间放一行空行。把任何相关__all__规范放在导入之后。
推荐 导入，因为它们更易读，并且如果导入系统配置的不正确（例如当包中的一个目录结束于sys.path）它们有更好的表现（至少给出更好的错误信息）：
明确的相对导入可以用来接受替代 导入，特别是处理复杂包布局时， 导入过于冗长。
标准库代码应该避免复杂包布局并使用 导入。
隐式的相对导入应该永远不被使用，并且在Python3中已经移除。
从一个包含类的模块中导入类时，通常下面这样是好的写法：
如果这种写法导致本地名字冲突，那么就这样写：
并使用“myclass.MyClass”和“foo.bar.yourclass.YourClass”来访问。
避免使用通配符导入（from模块名import*），因为它们使哪些名字出现在命名空间变得不清楚，这混淆了读者和许多自动化工具。通配符导入有一种合理的使用情况，重新发布一个内部接口作为一个公共API的一部分（例如，重写一个纯Python实现的接口，该接口定义从一个可选的加速器模块并且哪些定义将被重写提前并不知道）。用这种方式重新命名，下面的有关公共和内部接口的指南仍适用。
模块级别的内置属性
模块级别的内置属性（名字有前后双下划线的），例如__all__,__author__,__vrsion__，应该放置在模块的文档字符串后，任意import语句之前，from__futur__导入除外。Python强制要求from__futur__导入必须在任何代码之前，只能在模块级文档字符串之后。
字符串引号
Python中，单引号字符串和双引号字符串是一样的。本PEP不建议如此。建议选择一条规则并坚持下去。当一个字符串包含单引号字符或双引号字符时，使用另一种字符串引号来避免字符串中使用反斜杠。这提高可读性。三引号字符串，与PEP文档字符串规范一致总是使用双引号字符。
表达式和语句中的空格
无法忍受的
以下情况避免使用多余的空格：
紧挨着小括号，中括号或大括号。
紧挨在逗号，分号或冒号前：
在切片中冒号像一个二元操作符，冒号两侧的有相等数量空格（把它看作 优先级的操作符）。在一个扩展切片中，两个冒号必须有相等数量的空格。例外：当一个切片参数被省略时，该空格被省略。
紧挨着左括号之前，函数调用的参数列表的开始处：
紧挨着索引或切片开始的左括号之前：
为了与另外的赋值（或其它）操作符对齐，不止一个空格。
其它建议
始终避免行尾空白。因为它们通常不可见，容易导致困惑：如果\后面跟了一个空格，它就不是一个有效的续行符了。很多编辑器不保存行尾空白，CPython项目中也设置了