What I propose below is a Behaviour (or Story) Driven Development domain-specific language for writing your tests in Python. This uses some tricks of how imports are done (via encoding) to dynamically translate the tests from the DSL into pure Python. Additional tricks are used to preserve the line numbers of errors, offer abbreviated asserts, and automatically pass local variables from parent to child scopes.
This is parallelizable for efficient test running, compiles to Python bytecode for efficiency, and follows the same style as doctests.
If you hate DSLs (hey, Python ain’t Ruby!) consider this to be a file-length docstring. If you don’t like doctests then consider this to be a template engine for tests. (Most modern template engines generate Python code…)
@gregglind
It's less of a hack when you think about how it's implemented. With a template engine like Mako, Jinja2, Genshi, or KID, you're taking a text template with embedded Python instructions (control structures, variable references, and possibly whole blocks of code) and generating a real Python source file from it. Python then process the file and produces an object (module) usually containing a class which is then imported and used by the rendering engine. This usually uses magic hidden inside a wrapper class.
This method simply uses a feature of Python in order to do the translation… which is a class. The end result is the same: Python sees Python code and bytecode compiles it, then it is run.