Day06-Python中下划线的5种含义你都知道吗？.pdfVIP

Python中下划线的5种含义你都知道吗？ 本文介绍了Python中单下划线和双下划线（dunder ）的各种含义和命名约定，名称 修饰（name mangling ）的工作原理，以及它如何影响你自己的Python类。 单下划线和双下划线在Python变量和方法名称中都各有其含义。有一些含义仅仅是依照 约定，被视作是对程序员的提示 - 而有一些含义是由Python解释器严格执行的。 如果你想知道 “Python变量和方法名称中单下划线和双下划线的含义是什么 ？” ，我会 尽我所能在这里为你解答。 在本文中 ，我将讨论以下五种下划线模式和命名约定 ，以及它们如何影响Python程序的 行为： 单前导下划线：_var 单末尾下划线：var_ 双前导下划线：__var 双前导和末尾下划线：__var__ 单下划线：_ 在文章结尾处 ，你可以找到一个简短的 “速查表” ，总结了五种不同的下划线命名约定 及其含义，以及一个简短的视频教程，可让你亲身体验它们的行为。 让我们马上开始！ 1. 单前导下划线 _var 当涉及到变量和方法名称时 ，单个下划线前缀有一个约定俗成的含义。 它是对程序员的 一个提示 - 意味着Python社区一致认为它应该是什么意思，但程序的行为不受影响。 下划线前缀 的含义是告知其他程序员 ：以单个下划线开头 的变量或方法仅供 内部使 用。 该约定在PEP 8中有定义。 这不是 Python强制规定的。 Python不像Java那样在 “私有”和 “公共”变量之间有很 强的区别。 这就像有人提出了一个小小的下划线警告标志，说： “嘿，这不是真的要成为类的公共接口的一部分。不去管它就好。“ 看看下面的例子： 如果你实例化此类，并尝试访问在__init__构造函数中定义的foo和_bar属性，会发生什 么情况？ 让我们来看看： 你会看到_bar中的单个下划线并没有阻止我们“进入”类并访问该变量的值。 这是因为Python中的单个下划线前缀仅仅是一个约定 - 至少相对于变量和方法名而言。 但是，前导下划线的确会影响从模块中导入名称的方式。 假设你在一个名为my_module的模块中有以下代码： 现在，如果使用通配符从模块中导入所有名称，则Python不会导入带有前导下划线的名 称（除非模块定义了覆盖此行为的__all__列表）： 顺便说一下 ，应该避免通配符导入 ，因为它们使名称空间中存在哪些名称不清楚。 为了 清楚起见，坚持常规导入更好。 与通配符导入不同，常规导入不受前导单个下划线命名约定的影响： 这一点可能有点令人困惑。 如果你遵循 PEP 8推荐 ，避免通配符导入 ，那么你真正需要 记住的只有这个： 单个下划线是一个 Python命名约定 ，表示这个名称是供 内部使用的。 它通常不 由 Python解释器强制执行，仅仅作为一种对程序员的提示。 2. 单末尾下划线 var_ 有时候 ，一个变量的最合适的名称已经被一个关键字所 占用。 因此 ，像class或def这样 的名称不能用作 Python中的变量名称。 在这种情况下 ，你可以附加一个下划线来解决 命名冲突： 总之 ，单个末尾下划线 （后缀 ）是一个约定 ，用来避免与 Python关键字产生命名冲 突。 PEP 8解释了这个约定。 3. 双前导下划线 __var 到 目前为止 ，我们所涉及的所有命名模式的含义 ，来 自于已达成共识的约定。 而对于以 双下划线开头的Python类的属性（包括变量和方法），情况就有点不同了。 双下划线前缀会导致Python解释器重写属性名称，以避免子类中的命名冲突。 这也 叫做名称修饰 （name mangling ） - 解释器更改变量的名称 ，以便在类被扩展的 时候不容易产生冲突。 这听起来很抽象。 因此，我组合了一个小小的代码示例来予以说明： 让我们用内置的dir()函数来看看这个对象的属性： 以上是这个对象属性 的列表 。 让我们来看看这个列表 ，并寻找我们 的原始变量名称 foo ，_bar和__baz - 我保证你会注意到一些有趣的变化。  self.foo变量在属性列表中显示为未修改为foo。 self._bar的行为方式相同 - 它以_bar的形式显示在类上。 就像我之前说过的 ，在这 种情况下，前导下划线仅仅是一个约定。 给程序员一个提示而已。 然而 ，对于self.__baz而言 ，情况看起来有点不同。 当你在该列表中搜索__baz时 ， 你会看不到