jinx/python-uncompyle6
1
Fork 0
mirror of https://github.com/rocky/python-uncompyle6.git synced 2025-08-04 01:09:52 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update doc

Browse Source
This commit is contained in:
rocky
2017-11-28 18:45:01 -05:00
parent 3becefab1f
commit 0637dd62d7
1 changed files with 28 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
README.rst
View File

@@ -17,11 +17,34 @@ source code. It accepts bytecodes from Python version 1.5, and 2.1 to
Why this? Why this?
--------- ---------
There were a number of decompyle, uncompyle, uncompyle2, uncompyle3 Ok, I'll say it: this software is amazing. It is a little more than
forks around. All of them came basically from the same code base, and just your normal hacky decompiler. Using compiler technology, the
almost all of them no were no longer actively maintained. Only one programs creates a parse tree of the program from the instructions;
handled Python 3, and even there, only 3.2 or 3.3 depending on which nodes at the upper levels that look like they come from a Python
code is used. This code pulls these together and moves forward. AST. So we can really classify and understand what's going on in
sections of instructions.
So another thing that makes this different from other CPython bytecode
decompilers is the ability to deparse just *fragments* of source code
and give source-code information around a given bytecode offset.
I use the tree fragments to deparse fragments of code inside my
trepan_ debuggers_. For that, bytecode offsets are recorded and
associated with fragments of the source code. This purpose, although
compatible with the original intention, is yet a little bit different.
See this_ for more information.
The idea of Python fragment deparsing given an instruction offset can
be used in showing stack traces or any program that wants to show a
location in more detail than just a line number. It can be also used
when source-code information does not exist and there is just bytecode
There were (and still are) a number of decompyle, uncompyle, uncompyle2,
uncompyle3 forks around. Almost all of them come basically from the
same code base, and (almost?) all of them are no longer actively
maintained. Only one handled Python 3, and even there, only 3.2 or 3.3
depending on which code is used. This code pulls these together and
moves forward.
This project has the most complete support for Python 3.3 and above This project has the most complete support for Python 3.3 and above
and the best all-around Python support. and the best all-around Python support.
@@ -31,22 +54,6 @@ bugs. In the issue trackers for other decompilers, you will find a
number of bugs we've found along the way. Very few to none of them are number of bugs we've found along the way. Very few to none of them are
fixed in the other decompilers. fixed in the other decompilers.
Another thing that makes this different from other CPython bytecode
decompilers is the ability to deparse just fragments and give
source-code information around a given bytecode offset.
I use this to deparse fragments of code inside my trepan_
debuggers_. For that, I need to record text fragments for all
bytecode offsets (of interest). This purpose although largely
compatible with the original intention is yet a little bit different.
See this_ for more information.
The idea of Python fragment deparsing given an instruction offset can
be used in showing stack traces or any program that wants to show a
location in more detail than just a line number. It can be also used
when source-code information does not exist and there is just bytecode
information.
Requirements Requirements
------------ ------------