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

旧城等待， 2022-07-14 13:15 291阅读 0赞

原文地址：[http://python.jobbole.com/81129/][http_python.jobbole.com_81129]

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

# 1、单下划线（\_） #

通常情况下，单下划线（\_）会在以下3种场景中使用：

## 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 作为一个名称： ##

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

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

## 1.3 国际化： ##

也许你也曾看到”\_“会被作为一个函数来使用。这种情况下，它通常用于实现国际化和本地化字符串之间翻译查找的函数名称，这似乎源自并遵循相应的C约定。例如，在[Django文档“转换”章节][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)

可以发现，场景二和场景三中的使用方法可能会相互冲突，所以我们需要避免在使用“\_”作为国际化查找转换功能的代码块中同时使用“\_”作为临时名称。

# 2、名称前的单下划线（如：\_shahriar） #

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

另外单下划线开头还有一种一般不会用到的情况在于使用一个 C 编写的扩展库有时会用下划线开头命名，然后使用一个去掉下划线的 Python 模块进行包装。如 struct 这个模块实际上是 C 模块 \_struct 的一个 Python 包装。

# 3、名称前的双下划线（如：\_\_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就不再执行轧压（改编）。

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

# 4、名称前后的双下划线（如：\_\_init\_\_） #

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

双下划线开头双下划线结尾的是一些 Python 的“魔术”对象，如类成员的 \_\_init\_\_、\_\_del\_\_、\_\_add\_\_、\_\_getitem\_\_ 等，以及全局的 \_\_file\_\_、\_\_name\_\_ 等。 Python 官方推荐永远不要将这样的命名方式应用于自己的变量或函数，而是按照文档说明来使用。虽然你也可以编写自己的特殊方法名，但不要这样做。

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

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

# 5、题外话 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\_\_ 被选中。

# 6、用 \_\_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。

# 7、总结： #

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.

# 8、Refer： #

\[1\] Importing \`\*\` in Python

[http://shahriar.svbtle.com/importing-star-in-python][Importing _ in Python]

\[2\] 理解Python的双下划线命名

[http://blog.csdn.net/zhu\_liangwei/article/details/7667745][http_blog.csdn.net_zhu_liangwei_article_details_7667745]

\[3\] Python 的类的下划线命名有什么不同？

[http://www.zhihu.com/question/19754941][http_www.zhihu.com_question_19754941]

\[4\] 用 \_\_all\_\_ 暴露接口

[http://python-china.org/t/725][http_python-china.org_t_725]

\[5\] python基础（7）：变量、参数、函数式编程 —— 关于Python中的变量命名规则

[http://my.oschina.net/leejun2005/blog/269921\#OSC\_h3\_3][http_my.oschina.net_leejun2005_blog_269921_OSC_h3_3]

[http_python.jobbole.com_81129]: http://python.jobbole.com/81129/
[Django]: https://docs.djangoproject.com/en/dev/topics/i18n/translation/
[Importing _ in Python]: http://shahriar.svbtle.com/importing-star-in-python
[http_blog.csdn.net_zhu_liangwei_article_details_7667745]: http://blog.csdn.net/zhu_liangwei/article/details/7667745
[http_www.zhihu.com_question_19754941]: http://www.zhihu.com/question/19754941
[http_python-china.org_t_725]: http://python-china.org/t/725
[http_my.oschina.net_leejun2005_blog_269921_OSC_h3_3]: http://my.oschina.net/leejun2005/blog/269921#OSC_h3_3