Python下划线与命名规范

在水一万

以下分四种情况说明下划线的作用，python对成员域没有严格控制，大部份只是作为命名规范存在，以下英文部份摘自python官方网站


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

_单下划线开头：弱“内部使用”标识，如：”from M import *”，将不导入所有以下划线开头的对象，包括包、模块、成员


single_trailing_underscore_: used 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; 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.
__双下划线开头双下划线结尾__：指那些包含在用户无法控制的命名空间中的“魔术”对象或属性，如类成员的__name__ 、__doc__、__init__、__import__、__file__、等。推荐永远不要将这样的命名方式应用于自己的变量或函数。
另外，以上说的大部分都是与模块成员相关的，包和模块的命名规范又有哪些需要注意的呢？

      Package and Module Names               

Modules should have short, all-lowercase names.  Underscores can be used
      in the module name if it improves readability.  Python packages should
      also have short, all-lowercase names, although the use of underscores is
      discouraged.     
                Since module names are mapped to file names, and some file systems are
      case insensitive and truncate long names, it is important that module
      names be chosen 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 use the CapWords convention.
      Classes for internal use have a leading underscore in addition.
类：几乎毫无例外的，类名都使用首字母大写开头(Pascal命名风格)的规范。使用_单下划线开头的类名为内部使用，上面说的from M import *默认不被告导入的情况。


    Exception Names

      Because exceptions should be classes, the class naming convention
      applies here.  However, you should use the suffix "Error" on your
      exception names (if the exception actually is an error).
异常：因为异常也是一个类，所以遵守类的命名规则。此外，如果异常实际上指代一个错误的话，应该使用“Error”做后缀

    Global Variable Names

      (Let's hope that these variables are meant for use inside one module
      only.)  The conventions are about the same as those for functions.

      Modules that are designed for use via "from M import *" should use the
      __all__ mechanism to prevent exporting globals, or use the older
      convention of prefixing such globals with an underscore (which you might
      want to do to indicate these globals are "module non-public").



    Function Names

      Function names should be lowercase, with words separated by underscores
      as necessary to improve readability.

      mixedCase is allowed only in contexts where that's already the
      prevailing style (e.g. threading.py), to retain backwards compatibility.
函数：小写、下划线分词，如def has_key(ch):


    Function and method arguments

      Always use 'self' for the first argument to instance methods.

      Always use 'cls' for the first argument to class methods.

      If a function argument's name clashes with a reserved keyword, it is
      generally better to append a single trailing underscore rather than use
      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

      Use the function naming rules: lowercase with words separated by
      underscores as necessary to improve readability.

      Use one leading underscore only for non-public methods and instance
      variables.

      To avoid name clashes with subclasses, use two leading underscores to
      invoke Python's name mangling rules.

      Python mangles these names with the class name: if class Foo has an
      attribute named __a, it cannot be accessed by Foo.__a.  (An insistent
      user could still gain access by calling Foo._Foo__a.)  Generally, double
      leading underscores should be used only to avoid name conflicts with
      attributes in classes designed to be subclassed.

      Note: there is some controversy about the use of __names (see below).


    Constants

       Constants are usually defined on a module level and written in all
       capital letters with underscores separating words.  Examples include
       MAX_OVERFLOW and TOTAL.