-This section is primarily a summary of Guido van Rossum and Barry
-Warsaw's `Style Guide for Python Code
-<http://www.python.org/dev/peps/pep-0008/>`_, and borrows heavily from
-it. Explanation of these rules and the reasoning behind them can be
-found therein. When in need of sample code or other examples, any common
-source code file or text document file distributed as part of mudpy
-should serve as a suitable reference.
-
-indentation
------------
-
-* Use 3 spaces per indentation level. (This is a deviation from Python
- PEP-8, which encourages 4-space tab stops, and as such the project may
- be reformatted to conform at some future date).
-
-tabs or spaces
---------------
-
-* Spaces only--no tabs ever. (Exception: Special file formats like `GNU
- ChangeLog <http://www.gnu.org/prep/standards/html_node/
- Style-of-Change-Logs.html#Style-of-Change-Logs>`_ require tabs for
- historical reasons.)
-
-maximum line length
--------------------
-
-* Limit all lines to a maximum of 79 characters.
-
-* For flowing long blocks of text (docstrings, comments, documentation
- files and text-based data files), limiting the length to 72 characters
- is recommended.
-
-* The preferred way of wrapping long lines is by using Python's implied
- line continuation inside parentheses, brackets and braces. Make sure
- to indent the continued line appropriately.
-
-* The preferred place to break around a binary operator is *after* the
- operator, not before it.
-
-* When bracketed code is expanded into multiple lines, its terminating
- bracket is indented the same amount as the line on which its
- corresponding initial bracket appears (essentially K&R style).
-
-* If bracketed parameters are too lengthy/numerous to fit together on
- one line, all are split onto individual lines.
-
-blank lines
------------
-
-* Separate top-level function and class definitions with two blank
- lines.
-
-* Method definitions inside a class are separated by a single blank
- line.
-
-* Extra blank lines may be used (sparingly) to separate groups of
- related functions.
-
-* Blank lines may be omitted between a bunch of related one-liners (e.g.
- a set of dummy implementations).
-
-* Use blank lines in functions, sparingly, to indicate logical sections.
-
-encodings
----------
-
-* Always use ASCII whenever possible (decimal byte values 32 through 126
- and line termination appropriate to the developer's platform).
-
-* UTF-8 can be used, but only when a comment or docstring needs to
- mention an author name that requires it; otherwise, using ``\x``,
- ``\u`` or ``\U`` escapes is the preferred way to include non-ASCII
- data in string literals.
-
-* Identifiers must be ASCII-only, and should use English words wherever
- feasible.
-
-* In addition, string literals and comments must also be in ASCII. The
- only exceptions are:
-
- - test cases testing the non-ASCII features, and
-
- - names of authors.
-
-* Any text constants in code are declared as Unicode; when actual byte
- data is required instead, its entry point is documented clearly in
- preparation for an eventual Python 3 transition.
-
-* All text handling routines operate on Unicode data, normalized as
- early as possible to eliminate compositing sequences.
-
-imports
--------