python
下划线 __
开头的变量
示例
# 以数字、字母开头: 正常的公有变量名
a = 1
def aa():
pass
# 以单下划线开头: 半私有的变量名
_b = 2
def _bb():
pass
# 以双下划线开头: 私有变量名
__c = 3
def __cc():
pass
# 以双下划线开头, 双下划线结尾: 内置属性名或者魔法方法名
__name__, __dir__
公有变量名
以此类名称命名的对象, 为公有对象, 任何人都可以使用。
半私有变量名
以此类名称命名的对象, 需要分为两种情况
- 类外
类外的半私有对象、私有对象, 功能一致, 均是在本模块中可以正常使用, 但是不能被直接导入并调用
如果一定要在模块外使用, 那么需要导入本模块, 然后使用 (模块名. 变量名) 进行调用
- 类中
类中的半私有对象, 仅仅是概念上的私有, 默认不要再类外进行调用
实际在类外, 均可以使用 (实例名. 变量名 / 类名. 变量名) 进行调用
私有变量名
以此类名称命名的对象, 也需要分为两种情况
- 类外
此种情况下的对象, 和半私有对象一样, 可参照上面
- 类中
类中的私有对象, 在类外均不能直接调用, 可以理解为真私有
但是, python 中没有完全私有的对象, 此种对象也是可以在类外进行调用的, 这里涉及到一个概念: 矫直
class A:
def get_1(self):
return 1
def _get_2(self):
return 2
def __get_3(self):
return 3
print(dir(A))
结果为:
['_A__get_3', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__',
'__weakref__', '_get_2', 'get_1']
从打印结果中我们看到, 类 A 并不存在 __get_3
这么一个属性, 但是存在一个 _A__get_3
的属性, 这就是矫直
python 对于出现在类中的私有属性或者私有方法, 进行矫直, 矫直方法就是在私有属性名、私有方法名前添加( _类名
)
那么, 我们想要调用类的私有属性和方法的时候, 就可以直接用矫直后的属性名进行调用。
魔法方法
这是 python 自己实现的属性和方法, 一般不允许自定义类似此种命名方式的属性或者方法。
错误与异常
raise 错误
raise ValueError("bad value!")
Python 命名中下划线的含义
Python 不仅用奇特的空格表示代码块, 还用变量和函数命名中的下划线来表示一些特殊含义, 现在总结如下:
_
单下划线开头: 弱 “内部使用” 标识, 如:from M import *
, 将不导入所有以下划线开头的对象, 包括包, 模块, 成员。- 单下划线结尾
_
: 只是为了避免与 python 关键字的命名冲突。 __
双下划线开头: 模块内的成员, 表示私有成员, 外部无法直接调用。__
双下划线开头双下划线结尾__
: 指那些 python 类中的特殊函数或属性, 如__name__
,__doc__
,__init__
,__import__
,__file__
,__setattr__
,__getattr__
,__dict__
等, 自己写变量和函数. 方法名不推荐这样的方式。
另外, python 中没有像 C++. Java 那样严格的成员域限制, __
双下划线开头成员标识是类私有成员, 但是实际上是伪私有, 可以通过其他途径直接访问, 比如:
变量:
- 前带
_
的变量: 标明是一个私有变量, 只用于标明, 外部类还是可以访问到这个变量 - 前带两个
_
, 后带两个_
的变量: 标明是内置变量, - 大写加下划线的变量: 标明是不会发生改变的全局变量
函数:
- 前带
_
的变量: 标明是一个私有函数, 只用于标明 - 前带两个
_
, 后带两个_
的函数: 标明是特殊函数
Python 的代码风格由 PEP 8 描述。这个文档描述了 Python 编程风格的方方面面。在遵守这个文档的条件下, 不同程序员编写的 Python 代码可以保持最大程度的相似风格。这样就易于阅读, 易于在程序员之间交流。