Basic concepts:
Use PyLint as the verification tool for code style
Start with base rules, and add additional ones every time we run into any ambiguous scenarios
Aspire to only support rules which can be verified automatically
Upon PyLint new release, consider the new base rules and possibly add new exceptions rather than changing the code to fit the new base rules
List of pylint builtin messages (rules): http://pylint-messages.wikidot.com/all-messages
List of additional rules:
Line width should be capped at 100 rather than the default 79
Exceptions
Exceptions are a means of breaking out of the normal flow of control of a code block to handle errors or other exceptional conditions.
Never use catch-all except: statements, or catch Exception or StandardError, unless you are re-raising the exception or in the outermost block in your thread (and printing an error message). Python is very tolerant in this regard and except: will really catch everything including misspelled names, sys.exit() calls, Ctrl+C interrupts, unittest failures and all kinds of other exceptions that you simply don't want to catch.
Power Features
It's very tempting to use these "cool" features when they're not absolutely necessary. It's harder to read, understand, and debug code that's using unusual features underneath. It doesn't seem that way at first (to the original author), but when revisiting the code, it tends to be more difficult than code that is longer but is straightforward.
Classes
If a class inherits from no other base classes, explicitly inherit from object. This also applies to nested classes.
Imports
Import modules and (and not attributes).
Use relative import when possible (while maintaining readability).
When importing several modules from the same package use ‘,’ and ‘(‘, ‘)’. e.g.:
From x import (a,
b)
6) Naming
if the variable is private/protected, use ‘_’ as a prefix to the variables name.
single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g. class_
7) between class declaration and any following member should be at least one empty line.
8) When creating a mixin class, the name should end with ‘mixin’ (not case sensitive) - this will enable ignoring missing members.
TODO: attach an updated PyLint configuration file