[Python-ideas] Standard (portable) bytecode "assembly" format

Nick Coghlan ncoghlan at gmail.com
Fri Feb 26 06:36:15 EST 2016


On 26 February 2016 at 15:27, Andrew Barnert via Python-ideas
<python-ideas at python.org> wrote:
> Of course we already have such a format today: dis.Bytecode.

I wouldn't feel beholden to hewing too closely to the existing dis API
- that was defined to solve a specific problem with making it easier
to test CPython's code generation pipeline, while also providing an
improved foundation for the dis text output. For those use cases, the
redundancy in the API is a help, rather than a hindrance, since we can
easily test and display all the values of interest.

For manipulation though, the redundancy is a problem - you need to
either declare some fields authoritative and implicitly derive the
others, or else expect users to keep things in sync manually (which
would be a pretty user hostile API).

I do think it's reasonable to seek to define a standard
MutableBytecode format specifically to make manipulation easier, but I
don't think it makes sense to couple that to PEP 511's definition of
bytecode processing.

The reason I feel that way is that I consider it *entirely acceptable*
for the first generation of bytecode post-processors to be based on
the disassemble-manipulate-reassemble model that folks already use for
bytecode manipulating function decorators, and for doing that
conveniently to be dependent on 3rd party libraries, at least for the
time being.

If we later settle on a standard mutable bytecode format, we may also
decide to introduce bytecode pre-processors that accept and produce
the pre-assembly form of the bytecode, but that's something to be done
as a possible compile time reduction measure *after* folks have
practical experience with the easier to define post-processing
approach, rather than before.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list