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

Update status

Browse Source
This commit is contained in:
rocky
2020-07-05 00:59:16 -04:00
parent b21e8b8b57
commit 1d3fdbb4cd
1 changed files with 38 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
README.rst
View File

@@ -68,10 +68,9 @@ are syntactically correct by running the Python interpreter for that
bytecode version. Finally, in cases where the program has a test for bytecode version. Finally, in cases where the program has a test for
itself, we can run the check on the decompiled code. itself, we can run the check on the decompiled code.
We are serious about testing, and use automated processes to find We use an automated processes to find bugs. In the issue trackers for
bugs. In the issue trackers for other decompilers, you will find a other decompilers, you will find a number of bugs we've found along
number of bugs we've found along the way. Very few to none of them are the way. Very few to none of them are fixed in the other decompilers.
fixed in the other decompilers.
Requirements Requirements
------------ ------------
@@ -172,11 +171,7 @@ All of the Python decompilers that I have looked at have problems
decompiling Python's control flow. In some cases we can detect an decompiling Python's control flow. In some cases we can detect an
erroneous decompilation and report that. erroneous decompilation and report that.
Python support is strongest in Python 2 for 2.7 and drops off as you Python support is pretty good for Python 2
get further away from that. Support is also probably pretty good for
python 2.3-2.4 since a lot of the goodness of early the version of the
decompiler from that era has been preserved (and Python compilation in
that era was minimal)
There is some work to do on the lower end Python versions which is There is some work to do on the lower end Python versions which is
more difficult for us to handle since we don't have a Python more difficult for us to handle since we don't have a Python
@@ -215,17 +210,42 @@ which use their own magic and encrypt bytecode. With the exception of
the Dropbox's old Python 2.5 interpreter this kind of thing is not the Dropbox's old Python 2.5 interpreter this kind of thing is not
handled. handled.
We also don't handle PJOrion_ obfuscated code. For that try: PJOrion We also don't handle PJOrion_ or otherwise obfuscated code. For
Deobfuscator_ to unscramble the bytecode to get valid bytecode before PJOrion try: PJOrion Deobfuscator_ to unscramble the bytecode to get
trying this tool. This program can't decompile Microsoft Windows EXE valid bytecode before trying this tool. This program can't decompile
files created by Py2EXE_, although we can probably decompile the code Microsoft Windows EXE files created by Py2EXE_, although we can
after you extract the bytecode properly. For situations like this, you probably decompile the code after you extract the bytecode
might want to consider a decompilation service like `Crazy Compilers properly. Handling pathologically long lists of expressions or
<http://www.crazy-compilers.com/decompyle/>`_. Handling statements is slow. We don't handle Cython_ or MicroPython_ which don't use bytecode.
pathologically long lists of expressions or statements is slow.
There are numerous bugs in decompilation. And that's true for every
other CPython decompiler I have encountered, even the ones that
claimed to be "perfect" on some particular version like 2.4.
There is lots to do, so please dig in and help. As Python progresses decompilation also gets harder because the
compilation is more sophisticated and the language itself is more
sophisticated. I suspect that attempts there will be fewer ad-hoc
attempts like unpyc37_ (which is based on a 3.3 decompiler) simply
because it is harder to do so. The good news, at least from my
standpoint, is that I think I understand what's needed to address the
problems in a more robust way. But right now until such time as
project is better funded, I do not intend to make any serious effort
to support Python versions 3.8 or 3.9, including bugs that might come
in. I imagine at some point I may be interested in it.
You can easily find bugs by running the tests against the standard
test suite that Python uses to check itself. At any given time, there are
dozens of known problems that are pretty well isolated and that could
be solved if one were to put in the time to do so. The problem is that
there aren't that many people who have been working on bug fixing.
Some of the bugs in 3.7 and 3.8 are simply a matter of back-porting
the fixes in decmopyle3.
You may run across a bug, that you want to report. Please do so. But
be aware that it might not get my attention for a while. If you
sponsor or support the project in some way, I'll prioritize your
issues above the queue of other things I might be doing instead.
See Also See Also
-------- --------