Python 下划线、双下划线|极客教程

单下划线和双下划线在Python变量名和方法名中都有各自的含义。有些仅仅是作为约定，用于提示开发人员；而另一些则对Python解释器有特殊含义。

你可能有些疑惑：“Python中变量名和方法名中的单下划线、双下划线到底有什么含义？”我将竭尽全力为你解释清楚。本节将讨论以下五种下划线模式和命名约定，以及它们各自如何影响Python程序的行为。

前置单下划线：_var
后置单下划线：var_
前置双下划线：__var
前后双下划线：__var__
单下划线：_

Python 下划线、双下划线 `_var`

当涉及变量名和方法名时，前置单下划线只有约定含义。它对于程序员而言是一种提示——Python社区约定好单下划线表达的是某种意思，其本身并不会影响程序的行为。

前置下划线的意思是提示其他程序员，以单下划线开头的变量或方法只在内部使用。PEP 8中定义了这个约定（PEP 8是最常用的Python代码风格指南。

详见PEP 8：“Style Guide for Python Code”。

不过，这个约定对Python解释器并没有特殊含义。与Java不同，Python在“私有”和“公共”变量之间并没有很强的区别。在变量名之前添加一个下划线更像是有人挂出了一个小小的下划线警告标志：“注意，这并不是这个类的公共接口。最好不要使用它。”
来看下面的例子：

class Test:
    def __init__(self):
        self.foo = 11
        self._bar = 23

如果实例化这个类并尝试访问在__init__构造函数中定义的foo和_bar属性，会发生什么情况？

我们来看看：

>>> t = Test()
>>> t.foo
11
>>> t._bar
23

可以看到，_bar前面的单下划线并没有阻止我们“进入”这个类访问变量的值。

这是因为Python中的前置单下划线只是一个公认的约定，至少在涉及变量名和方法名时是这样的。但是前置下划线会影响从模块中导入名称的方式。假设在一个名为my_module的模块中有以下代码：

# my_module.py：

def external_func():
    return 23
def _internal_func():
    return 42

现在，如果使用通配符导入从这个模块中导入所有名称，Python不会导入带有前置单下划线的名称（除非模块中定义了__all__列表覆盖了这个行为：

>>> from my_module import *
>>> external_func()
23
>>> _internal_func()
NameError: "name '_internal_func' is not defined"

顺便说一下，应避免使用通配符导入，因为这样就不清楚当前名称空间中存在哪些名称了。¹⁰为了清楚起见，最好坚持使用常规导入方法。与通配符导入不同，常规导入不受前置单下划线命名约定的影响：

>>> import my_module
>>> my_module.external_func()
23
>>> my_module._internal_func()
42

这里可能有点混乱。但如果你遵循PEP 8的建议不使用通配符导入，那么真正需要记住的只有下面这一条。
以单下划线开头的名称只是Python命名中的约定，表示供内部使用。它通常对Python解释器没有特殊含义，仅仅作为对程序员的提示。

Python 下划线、双下划线 `var_`

有时，某个变量最合适的名称已被Python语言中的关键字占用。因此，诸如class或def的名称不能用作Python中的变量名。在这种情况下，可以追加一个下划线来绕过命名冲突：

>>> def make_object(name, class):
SyntaxError: "invalid syntax"

>>> def make_object(name, class_):
...     pass

总之，用一个后置单下划线来避免与Python关键字的命名冲突是一个约定。PEP 8定义并解释了这个约定。

Python 下划线、双下划线前置双下划线：`__var`

迄今为止，我们介绍的命名模式只有约定的意义，但使用以双下划线开头的Python类属性（变量和方法）就不一样了。

双下划线前缀会让Python解释器重写属性名称，以避免子类中的命名冲突。

这也称为名称改写（name mangling），即解释器会更改变量的名称，以便在稍后扩展这个类时避免命名冲突。

听起来很抽象，下面用代码示例来实验一下：

class Test:
    def __init__(self):
        self.foo = 11
        self._bar = 23
        self.__baz = 42

接着用内置的dir()函数来看看这个对象的属性：

>>> t = Test()
>>> dir(t)
['_Test__baz', '__class__', '__delattr__', '__dict__',
 '__dir__', '__doc__', '__eq__', '__format__', '__ge__',
 '__getattribute__', '__gt__', '__hash__', '__init__',
 '__le__', '__lt__', '__module__', '__ne__', '__new__',
 '__reduce__', '__reduce_ex__', '__repr__',
 '__setattr__', '__sizeof__', '__str__',
 '__subclasshook__', '__weakref__', '_bar', 'foo']

该函数返回了一个包含对象属性的列表。在这个列表中尝试寻找之前的变量名称foo、_bar和__baz，你会发现一些有趣的变化。

首先，self.foo变量没有改动，在属性列表中显示为foo。

接着，self._bar也一样，在类中显示为_bar。前面说了，在这种情况下前置下划线仅仅是一个约定，是对程序员的一个提示。

然而self.__baz就不一样了。在该列表中找不到__baz这个变量。
__baz到底发生了什么？

仔细观察就会看到，这个对象上有一个名为_Test__baz的属性。这是Python解释器应用名称改写之后的名称，是为了防止子类覆盖这些变量。

接着创建另一个类来扩展Test类，并尝试覆盖之前构造函数中添加的属性：

class ExtendedTest(Test):
    def __init__(self):
        super().__init__()
        self.foo = 'overridden'
        self._bar = 'overridden'
        self.__baz = 'overridden'

现在你认为这个ExtendedTest类实例上的foo、_bar和__baz值会是什么？来一起看看：

>>> t2 = ExtendedTest()
>>> t2.foo
'overridden'
>>> t2._bar
'overridden'
>>> t2.__baz
AttributeError:
"'ExtendedTest' object has no attribute '__baz'"

等一下，当试图访问t2.__baz的值时，为什么会得到AttributeError？因为Python又进行了名称改写！实际上，这个对象甚至没有__baz属性：

>>> dir(t2)
['_ExtendedTest__baz', '_Test__baz', '__class__',
 '__delattr__', '__dict__', '__dir__', '__doc__',
 '__eq__', '__format__', '__ge__', '__getattribute__',
 '__gt__', '__hash__', '__init__', '__le__', '__lt__',
 '__module__', '__ne__', '__new__', '__reduce__',
 '__reduce_ex__', '__repr__', '__setattr__',
 '__sizeof__', '__str__', '__subclasshook__',
 '__weakref__', '_bar', 'foo', 'get_vars']

可以看到，为了防止意外改动，__baz变成了_ExtendedTest__baz，但原来的_Test__baz还在：

>>> t2._ExtendedTest__baz
'overridden'
>>> t2._Test__baz
42

程序员无法感知双下划线名称改写，下面的例子可以证实这一点：

class ManglingTest:
    def __init__(self):
        self.__mangled = 'hello'

    def get_mangled(self):
        return self.__mangled

>>> ManglingTest().get_mangled()
'hello'
>>> ManglingTest().__mangled
AttributeError:
"'ManglingTest' object has no attribute '__mangled'"

名称改写也适用于方法名，会影响在类环境中所有以双下划线（dunder）开头的名称：

class MangledMethod:
    def __method(self):
        return 42

    def call_it(self):
        return self.__method()

>>> MangledMethod().__method()
AttributeError:
"'MangledMethod' object has no attribute '__method'"
>>> MangledMethod().call_it()
42

下面这个名称改写的示例可能会令人惊讶：

_MangledGlobal__mangled = 23

class MangledGlobal:
    def test(self):
        return __mangled

>>> MangledGlobal().test()
23

这个例子先声明_MangledGlobal__mangled为全局变量，然后在名为MangledGlobal的类环境中访问变量。由于名称改写，类中的test()方法仅用__mangled就能引用_MangledGlobal__mangled全局变量。

__mangled以双下划线开头，因此Python解释器自动将名称扩展为_MangledGlobal__mangled。这表明名称改写不专门与类属性绑定，而是能够应用于类环境中所有以双下划线开头的名称。

这里需要掌握的内容确实有点多。

说实话，我也没有把这些例子和解释记在大脑中，所以当初撰写这些例子的时候花了一些时间研究和编辑。虽然我有多年的Python使用经验，但大脑中并没有一直记着这样的规则和特殊情形。

有时，程序员最重要的技能是“模式识别”，以及知道查找哪些内容。如果你目前还有点不知所措，不要担心，慢慢来，继续尝试本章中的例子。

深入掌握这些概念之后，你就能识别出名称改写和刚刚介绍的其他行为给程序带来的影响。如果有一天在实际工作中遇到相关问题，你应该知道在文档中搜索哪些信息。

补充内容：什么是dunder

如果你听过一些有经验的Python高手谈论Python或者看过几次Python会议演讲，可能听说过dunder这个词。如果你还不知道这是什么意思，答案马上揭晓。

在Python社区中通常称双下划线为dunder。因为Python代码中经常出现双下划线，所以为了简化发音，Python高手通常会将“双下划线”（double underscore）简称为dunder

例如，__baz在英文中读作dunderbaz。与之类似，__init__读作dunderinit，虽然按道理说应该是dunderinitdunder。

但这只是命名约定中的另一个癖好，就像是Python开发人员的暗号。

Python 下划线、双下划线 `var`

这也许有点令人惊讶——如果名字前后都使用双下划线，则不会发生名称改写。前后由双下划线包围的变量不受Python解释器的影响：

class PrefixPostfixTest:
    def __init__(self):
        self.__bam__ = 42

>>> PrefixPostfixTest().__bam__
42

然而，同时具有前后双下划线的名称在Python中有特殊用途。像__init__这样的对象构造函数，用来让对象可调用的__call__函数，都遵循这条规则。

这些双下划线方法通常被称为魔法方法，但Python社区中的许多人（包括我自己）不喜欢这个词。因为这个词像是暗示人们要退避三舍，但实际上完全不必如此。双下划线方法是Python的核心功能，应根据需要使用，其中并没有什么神奇或晦涩的内容。

但就命名约定而言，最好避免在自己的程序中使用以双下划线开头和结尾的名称，以避免与Python语言的未来变更发生冲突。