带变量和方法的下划线vs双下划线[重复]

带变量和方法的下划线vs双下划线[重复]

从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.__private

just变成了

MyClass._MyClass__private

。（请注意，即使对于与超类同名的子类，也是如此，例如，在不同模块中的子类。）可以

__private

从类外部访问名称，只是不方便且易碎（这增加了对确切名称的依赖）超类）。

问题在于，类的作者可能会合理地认为“此属性/方法名称应是私有的，只能从该类定义中访问”并使用

__private

约定。但是稍后，该类的用户可能会创建合法需要访问该名称的子类。因此，要么必须修改超类（可能很难或不可能），要么子类代码必须使用手动修改的名称（充其量是丑陋和脆弱的）。

Python中有一个概念：“我们都同意这里的成年人”。如果使用

__private

表单，您将保护谁免受该属性的侵害？子类的职责是正确使用父类的属性，而父类的职责是正确地记录其属性。

最好使用单引号下划线约定

_internal

。“这根本没有弄乱名字；它只是向其他人表明要注意这一点，这是内部实现的细节；如果您不完全了解它，请不要触摸它。”但这只是一个惯例。