Author zyasoft
Recipients Arfrever, JJ, dahlia, fwierzbicki, griels, pjac, tuska, zart, zyasoft
Date 2014-05-20.17:05:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I don't think we want to be building modified JVMs.

As a workaround until Python bytecode compilation is directly incorporated into a future Jython (at the earliest, 2.7.1), I could readily write a PyPI package as part of jythontools ( that uses CPython 2.7 as a subprocess to compile Python source to Python bytecode via the compile() builtin and compileall. Such Python bytecode can be loaded via standard Python tooling (marshal.Unmarshaller) or pycimport, a metaimporter.

Python bytecode does not have such size limits and using it has other potential advantages, such as reducing permgen pressure, Jython startup time, Android support, and optimizations for invokedynamic. Not only is it used by CPython, it is also used by PyPy, and we have support it in Jython via org.python.core.PyBytecode, a direct port of ceval.c from CPython. Realizing all of these advantages will of course require getting Python bytecode compilation in Jython itself.

In the meantime, such a package would also be useful in testing Jython support in the regrtest of PyBytecode. We can also look at changing the unmarshalling such that it canonicalizes float literals to avoid regrtest errors around floating point representation.

Thoughts, especially on API, as we support this transition to native support? At a minimum, I would expect this package to be a direct substitute for compile and compileall, including the possibility of monkeypatching.

(Java bytecode of course would remain the usual way we support compiling Python source on Jython.)
Date User Action Args
2014-05-20 17:05:47zyasoftsetmessageid: <>
2014-05-20 17:05:47zyasoftsetrecipients: + zyasoft, fwierzbicki, tuska, pjac, Arfrever, dahlia, zart, JJ, griels
2014-05-20 17:05:47zyasoftlinkissue1891 messages
2014-05-20 17:05:46zyasoftcreate