[Python-Dev] Intention to accept PEP 552 soon (deterministic pyc files)
Guido van Rossum
guido at python.org
Thu Oct 5 10:32:28 EDT 2017
Honestly I think the API for accessing historic pyc headers should itself
also be 3rd party. CPython itself should not bother (backwards
compatibility with pyc files has never been a feature).
On Thu, Oct 5, 2017 at 6:44 AM, Barry Warsaw <barry at python.org> wrote:
> On Oct 4, 2017, at 13:53, Benjamin Peterson <benjamin at python.org> wrote:
> > It might be helpful to enumerate the usecases for such an API. Perhaps a
> > narrow, specialized API could satisfy most needs in a supportable way.
> 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.
> 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.
> 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.
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev