Le jeudi 14 avril 2016, Nick Coghlan email@example.com a écrit :
IHMO it's not a big deal to update these projects for the future Python 3.6. I can even help them to support the new bytecode format.
We've also had previous discussions on adding a "minimum viable bytecode editing" API to the standard library, and updating these third party modules to support wordcode instead of bytecode could provide a good use-case-driven opportunity for defining that (i.e. it wouldn't be about providing an end user facing API directly, but rather about letting CPython take care of the bookkeeping details for things like lnotab and sorting out jump targets).
Yeah, I know well this discussion since it started with my PEP 511. I wrote the bytecode as a tool for the discussion, to try to understand better the use case. The main task was to design the API.
I first looked at byteplay and codetranformer projects, but I found some issues in their design. Their API has some design issues. IMHO their API is not the best to modify bytecode.
My goal is to support Bytecode.from_code(code).to_code()==code: store enough information to be able to emit again exactly the same bytecode (line numbers, exact argument value, etc.).
I started with a long email, but I decided to document differences in bytecode documentation: https://bytecode.readthedocs.org/en/latest/byteplay_codetransformer.html