从PEP 8：

• _single_leading_underscore：“内部使用”指示器较弱。例如

from M import *

不导入名称以下划线开头的对象。

• single_trailing_underscore_：按惯例用于避免与Python关键字发生冲突，例如

Tkinter.Toplevel(master, class_='ClassName')

* __double_leading_underscore：在命名类属性时，调用名称修改（在class内FooBar，__boo成为_FooBar__boo;见下文）。

* __double_leading_and_trailing_underscore__：位于用户控制的名称空间中的“魔术”对象或属性。例如__init__，
__import__或__file__。请勿发明此类名称；仅按记录使用它们。

另外，来自David Goodger的《
Pythonista
之类的代码》：

属性：interface，_internal，__private

但是，请尽量避免使用该__private表格。我从不使用它。相信我。如果您使用它，您稍后会后悔。

说明：

来自C / Java背景的人们特别容易过度使用/滥用此“功能”。但是__private名称的作用方式不同于Java或C
。它们只是触发名称修改，其目的是防止子类中意外的名称空间冲突：
MyClass.__privatejust变成了MyClass._MyClass__private。（请注意，即使对于与超类同名的子类，也是如此，例如，在不同模块中的子类。）可以__private从类外部访问名称，只是不方便且易碎（这增加了对确切名称的依赖）超类）。

问题在于，类的作者可能会合理地认为“此属性/方法名称应是私有的，只能从该类定义中访问”并使用__private约定。但是稍后，该类的用户可能会创建合法需要访问该名称的子类。因此，要么必须修改超类（可能很难或不可能），要么子类代码必须使用手动修改的名称（充其量是丑陋和脆弱的）。

Python中有一个概念：“我们都同意这里的成年人”。如果使用__private表单，您将保护谁免受该属性的侵害？子类的职责是正确使用父类的属性，而父类的职责是正确地记录其属性。

最好使用单引号下划线约定
_internal。“这根本没有弄乱名字；它只是向其他人表明要注意这一点，这是内部实现的细节；如果您不完全了解它，请不要触摸它。”但这只是一个惯例。