Le jeudi 14 avril 2016, Nick Coghlan <ncoghlan at gmail.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 Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4