<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 October 2017 at 23:44, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Oct 4, 2017, at 13:53, Benjamin Peterson <<a href="mailto:benjamin@python.org">benjamin@python.org</a>> wrote:<br>
<br>
> It might be helpful to enumerate the usecases for such an API. Perhaps a<br>
> narrow, specialized API could satisfy most needs in a supportable way.<br>
<br>
</span>Currently `python -m dis thing.py` compiles the source then disassembles it.  It would be kind of cool if you could pass a .pyc file to -m dis, in which case you’d need to unpack the header to get to the code object.  A naive implementation would unpack the magic number and refuse to disassemble any files that don’t match whatever that version of Python understands.  A more robust (possibly 3rd party) implementation could potentially disassemble a range of magic numbers and formats, and an API to get at the code object and metadata would help.<br>
<br>
I was thinking about the bytecode hacking that some debuggers do.  This API would help them support multiple versions of Python.  They could use the API to discover what pyc format was in use, extract the code object, hack the bytecode and possibly rewrite a new PEP 3147 style pyc file with the debugger bytecodes inserted.<br>
<br>
Third party bytecode optimizers could use the API to unpack multiple versions of pyc files, do their optimizations, and rewrite new files with the proper format.<br></blockquote><div><br></div>Actually doing that properly also requires keeping track of which opcodes were valid in different versions of the eval loop, so as Guido suggests, such an abstraction layer would make the most sense as a third party project that tracked:</div><div class="gmail_quote"><br></div><div class="gmail_quote">- the magic number for each CPython feature release (plus the 3.5.3+ anomaly)</div><div class="gmail_quote">- the pyc header format for each CPython feature release<br></div><div class="gmail_quote">- the valid opcode set for each CPython feature release</div><div class="gmail_quote">- any other version dependent variations (e.g. the expected stack layout for BUILD_MAP changed in Python 3.5, when the evaluation order for dict displays was updated to be key then value, rather than the other way around)<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>