PEP 8 -- Style Guide for Python Code (4)

Naming Conventions
1. Names to Avoid
  a. Never use the characters `l' (lowercase letter el), `O' (uppercase letter oh), or `I' (uppercase letter eye) as single character variable names.
  b. In some fonts, these characters are indistinguishable from the numerals one and zero. When tempted to use `l', use `L' instead.

2. Package and Module Names
  a. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
  b. 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.

3. Class Names
  a. Class names use the CapWords convention. Classes for internal use have a leading underscore in addition.

4. Exception Names
  a. 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).

5. Global Variable Names
  a. (Let's hope that these variables are meant for use inside one module only.) The conventions are about the same as those for functions.
  b. 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").

6. Function Names
  a. Function names should be lowercase, with words separated by underscores as necessary to improve readability.
  b. mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

7. Function and method arguments
  a. Always use 'self' for the first argument to instance methods.
  b. Always use 'cls' for the first argument to class methods.
  c. 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.)

8. Method Names and Instance Variables
  a. Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.
  b. Use one leading underscore only for non-public methods and instance variables.
  c. To avoid name clashes with subclasses, use two leading underscores to invoke Python's name mangling rules.
  d. 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.

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

10. Designing for inheritance
  a. Public attributes should have no leading underscores.
  b. If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling.
  c. For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods.
  d. If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores.