python中类的命名规则_python命名规则
1. 以⼀个下划线开头的标识符(_xxx)，不能访问的类属性，但可通过类提供的接⼝进⾏访问，不会被语句 “from module import *” 语句加载surgery
2. 以两个下划线开头的标识符(__xxx)，在类中是类私有变量
3. 以两个下划线开头和结尾的标识符(__xxx__)，是系统定义的，具有特殊意义的标识符 ⽤户尽量不要⾃定义此类型的标识符(除⾮特殊需求)
4. 标识符单下划线(_)在 交互式的带提⽰符的解释器 下保存最后⼀个表达式的结果 以下分四种情况说明下划线的作⽤，python对成员域没有严格控制，⼤部份只是作为命名规范存在，以下英⽂部份摘⾃python官⽅⽹站
_single_leading_underscore: weak “internal u” indicator. E.g. “from M import *” does not import objects who name starts with an underscore.
_单下划线开头：弱“内部使⽤”标识，如：”from M import *”，将不导⼊所有以下划线开头的对象，包括包、模块、成员
single_trailing_underscore_: ud by convention to avoid conflicts with
初中英语语法口诀
Python keyword, e.g.Tkinter.Toplevel(master, class_=’ClassName’)
单下划线结尾_：只是为了避免与python关键字的命名冲突
__double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo; e below).
__双下划线开头：模块内的成员，表⽰私有成员，外部⽆法直接调⽤
__double_leading_and_trailing_underscore__: “magic” objects or
attributes that live in ur-controlled namespaces. E.g. __init__,__import__ or __file__. Never invent such names; only u them as documented.
__双下划线开头双下划线结尾__：指那些包含在⽤户⽆法控制的命名空间中的“魔术”对象或属性，如类成员的__name__ 、__doc__、
__init__、__import__、__file__、等。推荐永远不要将这样的命名⽅式应⽤于⾃⼰的变量或函数。 另外，以上说的⼤部分都是与模块成员相关的，包和模块的命名规范⼜有哪些需要注意的呢？
Package and Module Names
Modules should have short, all-lowerca names. Underscores can be ud
in the module name if it improves readability. Python packages should
also have short, all-lowerca names, although the u of underscores is
discouraged. Since module names are mapped to file names, and some file systems are
ca innsitive and truncate long names, it is important that module
names be chon to be fairly short — this won’t be a problem on Unix,
but it may be a problem when the code is transported to older Mac or
Windows versions, or DOS.
包和模块：模块应该使⽤尽可能短的、全⼩写命名，可以在模块命名时使⽤下划线以增强可读性。同样包的命名也应该是这样的，虽然其并不⿎励下划线。
以上这些主要是考虑模块名是与⽂件夹相对应的，因此需要考虑⽂件系统的⼀些命名规则的，⽐如Unix系统对⼤⼩写敏感，⽽过长的⽂件名会影响其在Windows/Mac/Dos等系统中的正常使⽤。
负担英语
Class Names
Almost without exception, class names u the CapWords convention.
Class for internal u have a leading underscore in addition.
so ho类：⼏乎毫⽆例外的，类名都使⽤⾸字母⼤写开头(Pascal命名风格)的规范。使⽤_单下划线开头的类名为内部使⽤，上⾯说的from M import *默认不被告导⼊的情况。
Exception Names
Becau exceptions should be class, the class naming convention常用日语
applies here. However, you should u the suffix “Error” on your
exception names (if the exception actually is an error).
异常：因为异常也是⼀个类，所以遵守类的命名规则。此外，如果异常实际上指代⼀个错误的话，应该使⽤“Error”做后缀
Global Variable Names
(Let’s hope that the variables are meant for u inside one module
only.) The conventions are about the same as tho for functions.
Modules that are designed for u via “from M import *” should u the
cartographer__all__ mechanism to prevent exporting globals, or u the older
convention of prefixing such globals with an underscore (which you might
want to do to indicate the globals are “module non-public”).
Function Names
Function names should be lowerca, with words parated by underscores
as necessary to improve readability.
听mixedCa is allowed only in contexts where that’s already the
prevailing style (e.g. threading.py), to retain backwards compatibility.
chernobyl函数：⼩写、下划线分词，如def has_key(ch):
Function and method arguments
Always u ‘lf’ for the first argument to instance methods.
Always u ‘cls’ for the first argument to class methods.
If a function argument’s name clashes with a rerved keyword, it is
generally better to append a single trailing underscore rather than u
an abbreviation or spelling corruption. Thus “print_” is better than
”prnt”. (Perhaps better is to avoid such clashes by using a synonym.)
Method Names and Instance Variables
U the function naming rules: lowerca with words parated by
underscores as necessary to improve readability.
hardly
U one leading underscore only for non-public methods and instance
variables.
To avoid name clashes with subclass, u two leading underscores to
invoke Python’s name mangling rules.
Python mangles the names with the class name: if class Foo has an attribute named __a, it cannot be accesd by Foo.__a. (An insistent ur could still gain access by calling Foo._Foo__a.) Generally, double leading underscores should be ud only to avoid name conflicts with attributes in class designed to be subclasd.
omsNote: there is some controversy about the u of __names (e below). Constants
Constants are usually defined on a module level and written in all capital letters with underscores parating words. Examples include MAX_OVERFLOW and TOTAL.
