single_trailing_underscore_: used by convention to avoid conflicts with

      Python keyword, e.g.Tkinter.Toplevel(master, class_='ClassName')

__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.

      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.

    Class Names

      Almost without exception, class names use the CapWords convention.

      Classes for internal use have a leading underscore in addition.

    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).

    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.

    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 *****es 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 *****es 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 *****es 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.