详解 Python 中的下划线命名规则

时间 2019-11-06

标签前端 python 程序员 django 编程 ide 函数式编程函数工具测试栏目 Python 繁體版

原文原文链接

在 python 中，下划线命名规则每每令初学者至关疑惑：单下划线、双下划线、双下划线还分先后……那它们的做用与使用场景到底有何区别呢？今天就来聊聊这个话题。前端

一、单下划线（_）

一般状况下，单下划线（_）会在如下3种场景中使用：python

1.1 在解释器中：

在这种状况下，“_”表明交互式解释器会话中上一条执行的语句的结果。这种用法首先被标准CPython解释器采用，而后其余类型的解释器也前后采用。程序员

>>> _ Traceback (most recent call last): 
File "<stdin>", line 1, in <module> 
NameError: name '_' is not defined 
>>> 42
>>> _ 
42
>>> 'alright!' if _ else ':('
'alright!'
>>> _ 
'alright!'

1.2 做为一个名称：

这与上面一点稍微有些联系，此时“_”做为临时性的名称使用。这样，当其余人阅读你的代码时将会知道，你分配了一个特定的名称，可是并不会在后面再次用到该名称。例如，下面的例子中，你可能对循环计数中的实际值并不感兴趣，此时就可使用“_”。django

n = 42
for _ in range(n): 
    do_something()

1.3 国际化：

也许你也曾看到”_“会被做为一个函数来使用。这种状况下，它一般用于实现国际化和本地化字符串之间翻译查找的函数名称，这彷佛源自并遵循相应的C约定。例如，在Django文档“转换”章节中，你将能看到以下代码：编程

from django.utils.translation import ugettext as _ 
from django.http import HttpResponse 
def my_view(request): 
    output = _("Welcome to my site.") 
    return HttpResponse(output)

能够发现，场景二和场景三中的使用方法可能会相互冲突，因此咱们须要避免在使用“_”做为国际化查找转换功能的代码块中同时使用“_”做为临时名称。ide

二、名称前的单下划线（如：_shahriar）

程序员使用名称前的单下划线，用于指定该名称属性为“私有”。这有点相似于惯例，为了使其余人（或你本身）使用这些代码时将会知道以“_”开头的名称只供内部使用。正如Python文档中所述：
如下划线“_”为前缀的名称（如_spam）应该被视为API中非公开的部分（无论是函数、方法仍是数据成员）。此时，应该将它们看做是一种实现细节，在修改它们时无需对外部通知。
正如上面所说，这确实相似一种惯例，由于它对解释器来讲确实有必定的意义，若是你写了代码“from <模块/包名> import *”，那么以“_”开头的名称都不会被导入，除非模块或包中的“__all__”列表显式地包含了它们。了解更多请查看“ Importing * in Python ”。
不过值得注意的是，若是使用 import a_module 这样导入模块，仍然能够用 a_module._some_var 这样的形式访问到这样的对象。函数式编程

另外单下划线开头还有一种通常不会用到的状况在于使用一个 C 编写的扩展库有时会用下划线开头命名，而后使用一个去掉下划线的 Python 模块进行包装。如 struct 这个模块其实是 C 模块 _struct 的一个 Python 包装。函数

三、名称前的双下划线（如：__shahriar）

名称（具体为一个方法名）前双下划线（__）的用法并非一种惯例，对解释器来讲它有特定的意义。Python中的这种用法是为了不与子类定义的名称冲突。Python文档指出，“__spam”这种形式（至少两个前导下划线，最多一个后续下划线）的任何标识符将会被“_classname__spam”这种形式原文取代，在这里“classname”是去掉前导下划线的当前类名。例以下面的例子：工具

>>> class A(object): 
...     def _internal_use(self): 
...         pass
...     def __method_name(self): 
...         pass
... 
>>> dir(A()) 
['_A__method_name', ..., '_internal_use']

正如所预料的，“_internal_use”并未改变，而“__method_name”却被变成了“_ClassName__method_name”：__开头的私有变量会在代码生成以前被转换为长格式（变为公有）。转换机制是这样的：在变量前端插入类名，再在前端加入一个下划线字符。这就是所谓的私有变量名字改编（Private name mangling）。此时，若是你建立A的一个子类B，那么你将不能轻易地覆写A中的方法“__method_name”，测试

>>> class B(A): 
...     def __method_name(self): 
...         pass
... 
>>> dir(B()) 
['_A__method_name', '_B__method_name', ..., '_internal_use']

然而若是你知道了这个规律，最终你仍是能够访问这个“私有”变量的。
私有变量名字改编意在给出一个在类中定义"私有"实例变量和方法的简单途径，避免派生类的实例变量定义产生问题，或者与外界代码中的变量搞混。
要注意的是混淆规则（私有变量名字改编）主要目的在于避免意外错误，被认做为私有的变量仍然有可能被访问或修改(使用_classname__membername)，在特定的场合它也是有用的，好比调试的时候。

上述的功能几乎和Java中的final方法和C++类中标准方法（非虚方法）同样。

再讲两点题外话：
一是由于轧压（改编）会使标识符变长，当超过255的时候，Python会切断，要注意所以引发的命名冲突。
二是当类名所有如下划线命名的时候，Python就再也不执行轧压（改编）。

不管是单下划线仍是双下划线开头的成员，都是但愿外部程序开发者不要直接使用这些成员变量和这些成员函数，只是双下划线从语法上可以更直接的避免错误的使用，可是若是按照 _类名__成员名则依然能够访问到。单下划线的在动态调试时可能会方便一些，只要项目组的人都遵照下划线开头的成员不直接使用，那使用单下划线或许会更好。

四、名称先后的双下划线（如：init）

这种用法表示Python中特殊的方法名。其实，这只是一种惯例，对Python系统来讲，这将确保不会与用户自定义的名称冲突。一般，你将会覆写这些方法，并在里面实现你所须要的功能，以便Python调用它们。例如，当定义一个类时，你常常会覆写“__init__”方法。

双下划线开头双下划线结尾的是一些 Python 的“魔术”对象，如类成员的 __init__、__del__、__add__、__getitem__ 等，以及全局的 __file__、__name__ 等。 Python 官方推荐永远不要将这样的命名方式应用于本身的变量或函数，而是按照文档说明来使用。虽然你也能够编写本身的特殊方法名，但不要这样作。

>>> class C(object): 
...     def __mine__(self): 
...         pass
... 
>>> dir(C) 
... [..., '__mine__', ...]

其实，很容易摆脱这种类型的命名，而只让Python内部定义的特殊名称遵循这种约定 :)

五、题外话 if name == "main":

全部的 Python 模块都是对象而且有几个有用的属性，你可使用这些属性方便地测试你所书写的模块。

模块是对象, 而且全部的模块都有一个内置属性 __name__。一个模块的 __name__ 的值要看您如何应用模块。若是 import 模块, 那么 __name__的值一般为模块的文件名, 不带路径或者文件扩展名。可是您也能够像一个标准的程序同样直接运行模块, 在这种状况下 __name__的值将是一个特别的缺省值：__main__。

>>> import odbchelper
>>> odbchelper.__name__
'odbchelper'

一旦了解到这一点, 您能够在模块内部为您的模块设计一个测试套件, 在其中加入这个 if 语句。当您直接运行模块, __name__ 的值是 __main__, 因此测试套件执行。当您导入模块, __name__的值就是别的东西了, 因此测试套件被忽略。这样使得在将新的模块集成到一个大程序以前开发和调试容易多了。
在 MacPython 上, 须要一个额外的步聚来使得 if __name__ 技巧有效。点击窗口右上角的黑色三角, 弹出模块的属性菜单, 确认 Run as __main__ 被选中。

六、用 all 暴露接口

Python 能够在模块级别暴露接口：

__all__ = ["foo", "bar"]

不少时候这么作仍是颇有好处的……

提供了哪些是公开接口的约定

不像 Ruby 或者 Java，Python 没有语言原生的可见性控制，而是靠一套须要你们自觉遵照的”约定“下工做。好比下划线开头的应该对外部不可见。一样，__all__ 也是对于模块公开接口的一种约定，比起下划线，__all__ 提供了暴露接口用的”白名单“。一些不如下划线开头的变量（好比从其余地方 import 到当前模块的成员）能够一样被排除出去。

import os
import sys

__all__ = ["process_xxx"]  # 排除了 `os` 和 `sys`

def process_xxx():
    pass  # omit

6.1 控制 from xxx import * 的行为

代码中固然是不提倡用 from xxx import * 的写法的（由于断定一个特殊的函数或属性是从哪来的有些困难，而且会形成调试和重构都更困难。），可是在 console 调试的时候图个方便仍是很常见的。若是一个模块 spam 没有定义 __all__，执行 from spam import * 的时候会将 spam 中非下划线开头的成员都导入当前命名空间中，这样固然就有可能弄脏当前命名空间。若是显式声明了 __all__，import * 就只会导入 __all__ 列出的成员。若是 __all__ 定义有误，列出的成员不存在，还会明确地抛出异常，而不是默默忽略。

6.2 为 lint 工具提供辅助

编写一个库的时候，常常会在 __init__.py 中暴露整个包的 API，而这些 API 的实现多是在包中其余模块中定义的。若是咱们仅仅这样写：

from foo.bar import Spam, Egg

一些代码检查工具，如 pyflakes 就会报错，认为 Spam 和 Egg 是 import 了又没被使用的变量。固然一个可行的方法是把这个警告压掉：

from foo.bar import Spam, Egg # noqa

可是更好的方法是显式定义 __all__，这样代码检查工具会理解这层意思，就再也不报 unused variables 的警告：

from foo.bar import Spam, Egg

__all__ = ["Spam", "Egg"]

须要注意的是大部分状况下 __all__ 都是一个 list，而不是 tuple 或者其余序列类型。若是写了其余类型的 __all__，如无心外 pyflakes 等 lint 工具会没法识别出。

6.3 定义 all 须要注意的地方

如上所述，__all__ 应该是 list 类型的

不该该动态生成 __all__，好比使用列表解析式。__all__ 的做用就是定义公开接口，若是不以字面量的形式显式写出来，就失去意义了。

即便有了 __all__ 也不该该在非临时代码中使用 from xxx import * 语法，或者用元编程手段模拟 Ruby 的自动 import。Python 不像 Ruby，没有 Module 这种成员，模块就是命名空间隔离的执行者。若是打破了这一层，并且引入诸多动态因素，生产环境跑的代码就充满了不肯定性，调试也会很是困难。

按照 PEP8 建议的风格，__all__ 应该写在全部 import 语句下面，和函数、常量等模块成员定义的上面。

若是一个模块须要暴露的接口改动频繁，__all__ 能够这样定义：

__all__ = [

    "foo",

    "bar",

    "egg",

]

最后多出来的逗号在 Python 中是容许的，也是符合 PEP8 风格的。这样修改一个接口的暴露就只修改一行，方便版本控制的时候看 diff。

七、总结：

Python 用下划线做为变量前缀和后缀指定特殊变量。
_xxx 不能用'from module import *'导入
__xxx__ 系统定义名字
__xxx 类中的私有变量名
核心风格：避免用下划线做为变量名的开头。
由于下划线对解释器有特殊的意义，并且是内建标识符所使用的符号，咱们建议程序员避免用下划线做为变量名的开头。

通常来说，变量名_xxx被看做是“私有的”，在模块或类外不可使用。当变量是私有的时候，用_xxx 来表示变量是很好的习惯。

由于变量名__xxx__对Python 来讲有特殊含义，对于普通的变量应当避免这种命名风格。
"单下划线" 开始的成员变量叫作保护变量，意思是只有类对象和子类对象本身能访问到这些变量；
"双下划线" 开始的是私有成员，意思是只有类对象本身能访问，连子类对象也不能访问到这个数据。
以单下划线开头（如_foo）的表明不能直接访问的类属性，需经过类提供的接口进行访问，不能用“from xxx import *”而导入（注意 import xxx 是能够访问的）；以双下划线开头的（如__foo）表明类的私有成员；以双下划线开头和结尾的（__foo__）表明python里特殊方法专用的标识，如 __init__() 表明类的构造函数。

附 PEP 规范：

PEP-0008:

In addition, the following special forms using leading or trailing underscores are recognized (these can generally be combined with any case convention):

    - _single_leading_underscore: weak "internal use" indicator. E.g. "from M import *" does not import objects whose name starts with an underscore.

    - single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g.

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

    - __double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo; see below).

    - __double_leading_and_trailing_underscore__: "magic" objects or attributes that live in user-controlled namespaces. E.g. __init__,
      __import__ or __file__. Never invent such names; only use them as documented.