the motivation is that py3k lacks many useful 2.x modules. the lack
of 3rd-party modules in particular (eg scipy, PIL, ...) is a hindrance to py3k
development/testing. py3to2 addresses these issues by allowing py3k code to b
developed/integrated/run natively under the robust, software-rich, py2x
environment.

MECHANISM:
1. upon init, py3to2 starts up a py3k server w/ pipe io.

2. -> received via pipe io from py3to2, the py3k server 1st
natively compiles the src code into a py3k codeobj, then converts it
to py2x format w/ the addition of the backported opcodes.

3. <- the serialized py2x codeobj is piped back to py3to2,
which unserializes it & eval/exec it as normal.

in theory, this mechanism should transparently implement any bytecode-level py3k
language feature. performance and robustness should b minimally impacted, since
the compiled code is directly run as native 2.x++ bytecode.