PythonTidy is a script that reads Python code from standard input and writes a revised version to standard output.
Alternatively, it may be invoked with file names as arguments:
- python PythonTidy.py input output
Suffice it to say that input defaults to '-', the standard input, and output defaults to '-', the standard output.
It means to encapsulate the wisdom revealed in:
- Rossum, Guido van, and Barry Warsaw. "PEP 8: Style Guide for Python Code." 23 Mar. 2006. Python.org. 28 Nov. 2006 < http://www.python.org/dev/peps/pep-0008/ >.
Python scripts are usually so good looking that no beautification is required. However, from time to time, it may be necessary to alter the style to conform to changing standards. This script converts programs in a consistent way. It abstracts the pretty presentation of the symbolic code from the humdrum process of writing it and getting it to work.
This script assumes that the input Python code is well-formed and works to begin with. It doesn't check. If all goes well, the output Python code will work, too. Of course, you are advised to test it fully to be sure.
This script should be run only by python.2.5 (and perhaps higher) on scripts written for that version (and perhaps lower) because of its limited knowledge of and expectations for the abstract syntax tree node classes returned by the compiler module. It wouldn't hurt much to try it from (and on) other versions, though, and it might actually work.
Search this script for "Python Version Dependency."
Most of the Python 2.5 test suite passes through PythonTidy.py unimpaired. I ran the Python regression tests for 2.5.2 which is the version supported by Debian 5.0 "Lenny."
On my system these tests fail before tidying:
- test_imageop o test_pyclbr o test_sys
282 tests succeed after tidying with the default PythonTidy global settings, but these tests fail:
test_grammar exposes bug 6978 in the compiler module. Tuples are immutable and hashable and thus suitable as dict indices. Whereas a singleton tuple literal (x,) is valid as an index, the compiler module parses it as x when it appears.
test_dis compares "disassembled" Python byte code to what is expected. While byte code for a tidied script should be functionally equivalent to the untidied version, it will not necessarily be identical.
test_trace compares the line numbers in a functional trace of a running script with those expected. A statement in a tidied script will generally have a line number slightly different from the same statement in the untidied version.
test_doctest is an extensive suite of tests of the doctest module, which itself is used to document test code within doc strings and at need to compare instant results against those expected. One of the tests in test_doctest appears to require line numbers consistent with expectations, but tidied scripts generally violate such conditions as explained above.
The more esoteric capabilities of PythonTidy.py had to be turned off to avoid corrupting the test-suite code. In practice, you'll want to run with PERSONAL = True to use all the functionality, and of course you'll have the good taste to find and patch all the glitches it introduces.