Changelog History
Page 1
-
v3.7.4 Changes
September 05, 2020- ๐ Fragment parsing was borked. This means deparsing in trepan2/trepan3k was broken
- 3.7+: narrow precedence for call tatement
- ๐ del_stmt -> delete to better match Python AST
- 3.8+ Add another
forelsestmt
(found only in a loop) - 3.8+ Add precedence on walrus operator
- More files blackened
- โฌ๏ธ bump min xdis version
-
v3.7.3 Changes
July 25, 2020๐ Mostly small miscellaneous bug fixes
__doc__ = DocDescr()
fromtest_descr.py
was getting confused as a docstring.- ๐ detect 2.7 exchandler range better
- โ Add for .. else reduction checks on 2.6 and before
- โ Add reduce check for 2.7 augmented assign
- โ Add VERSION in a pydoc-friendly way
-
v3.7.2 Changes
June 28, 2020- ๐ Use newer
xdis
- ๐ Docstrings (again) which were broken again on earlier Python
- ๐ Fix 2.6 and 2.7 decompilation bug in handling "list if" comprehensions
- ๐ Use newer
-
v3.7.1 Changes
June 13, 2020๐ Released to pick up new xdis version which has fixes to read bytestings better on 3.x
- ๐ Handle 3.7+ "else" branch removal adAs seen in
_cmp()
ofpython3.8/distutils/version.py
with optimization-O2
- 3.6+ "with" and "with .. as" grammar improvements
- ast-check for "for" loop was missing some grammar rules
- ๐ Handle 3.7+ "else" branch removal adAs seen in
-
v3.7.0 Changes
May 19, 2020๐ The main impetus for this release is to pull in the recent changes from xdis.
We simplify imports using xdis 4.6.0.๐ There were some bugfixes to Python 3.4-3.8. See the ChangeLog for details
-
v3.6.6 Changes
May 19, 2020๐ The main reason for this release is an incompatablity bump in xdis which handles
๐ 3.7 SipHash better.- Go over "yield" as an expression precidence
- Some small alignment with code in decompyle3 for "or" and "and" was done
-
v3.6.5 Changes
April 01, 2020Back port some of the changes in decompile3 here which mostly helps 3.7 and 3.8 decompilation, although this may also help 3.6ish versions too.
- ๐ Handle nested
async for in for...
and better async comprehension detection viaxdis
. Still more work is needed. - ๐ include token number in listings when
-g
and there is a parser error - โ remove unneeded
Makefile
s now that remake 4.3+1.5dbg is a thing that has-c
- ๐ Bug in finding annotations in functions with docstrings
- ๐ Fix bug found by 2.4 sre_parse.py testing
- ๐ Fix
transform
module'sifelseif
bugs - ๐ Fix bug in 3.0 name module detection
- ๐ Fix docstring detection
- ๐ Handle nested
-
v3.6.4 Changes
February 09, 2020๐ The main focus in this release was fix some of the more glaring problems creapt in from the last release due to that refactor.
๐จ
uncompyle6
code is at a plateau where what is most needed is a code refactoring. In doing this, until everything refactored and replaced, decomplation may get worse.๐ Therefore, this release largely serves as a checkpoint before more major upheaval.
๐ The upheaval, in started last release, I believe the pinnicle was around c90ff51 which wasn't a release. I suppose I should tag that.
๐ After c90ff5, I started down the road of redoing control flow in a more comprehensible, debuggable, and scalable way. See The Control Flow Mess.
๐จ The bulk of the refactoring going on in the decompyle3 project, but I try to trickle down the changes.
โ It is tricky because the changes are large and I have to figure decompose things so that little testable pieces can be done. And there is also the problem that what is in decompyle3 is incomplete as well.
๐ Other than control flow, another change that will probably happen in the next release is to redo the grammar for lambda expressions. Right now, we treat them as Python statements, you know, things with compound statements in them. But lambdas aren't that. And so there is hackery to paper over difference making a statement out of an expression the wrong thing to do. For example, a return of an "and" expression can be expressed as nested "if" statements with return inside them, but the "if" variant of the bytecode is not valid in a lambda.
๐ In the decompyle3 code, I've gone down the road making the grammar goal symbol be an expression. This also offers the opportunity to split the grammar making parsing inside lambda not only more reliable because the wrong choices don't exist, but also simpler and faster because all those rules just need don't need to exist in parsing.
I cringe in thinking about how the code has lived for so long without noticing such a simple stupidity, and lapse of sufficient thought.
โ Some stats from testing. The below give numbers of decompiled tests from Python's test suite which succesfully ran
Version test-suites passing ------- ------------------- 2.4.6 243 2.5.6 265 2.6.9 305 3.3.7 300 3.4.10 304 3.5.9 260 3.6.10 236 3.7.6 306 3.8.1 114
Decompiled bytecode files distributed with Python (syntax check only):
2.7.17 647 files: 0 failed 3.2.6 900 files: 0 failed 3.3.7 1256 files: 0 failed 3.4.10 800 files: 0 failed 3.5.9 900 files: 0 failed 3.6.10 1300 files: 28 failed
-
v3.6.3 Changes
January 26, 2020๐ Of late, every release fixes major gaps and embarrassments of the last release....
And in some cases, like this one, exposes lacuna and rot.
I now have [control] flow under control, even if it isn't the most optimal way.
โ I now have greatly expanded automated testing.
๐ท On the most recent Python versions I regularly decompile thousands of Python programs that are distributed with Python. when it is possible, I then decompile Python's standard test suite distributed with Python and run the decompiled source code which basically checks itself. This amounts to about 250 test programs per version. This is in addition to the 3 CI testing services which do different things.
Does this mean the decompiler works perfectly? No. There are still a dozen or so failing programs, although the actual number of bugs is probably smaller though.
๐ However, in perparation of a more major refactoring of the parser grammar, this release was born.
๐จ In many cases, decompilation is better. But there are some cases where decompilation has gotten worse. For lack of time (and interest) 3.0 bytecode suffered a hit. Possibly some code in the 3.x range did too. In time and with cleaner refactored code, this will come back.
Commit c90ff51 was a local maxiumum before, I started reworking the grammar to separate productions that were specific to loops versus those that are not in loops.
๐ In the middle of that I added another grammar simplication to remove singleton productions of the formsstmts-> stmts
. These were always was a bit ugly, and complicated output.At any rate if decompilation fails, you can try c90ff51. Or another decompiler.
unpyc37
is pretty good for 3.7. wibitiuncompyle2
is great for 2.7.pycdc
is mediocre for Python before 3.5 or so, and not that good for the most recent Python. Generally these programs will give some sort of answer even if it isn't correct.๐ decompyle3 isn't that good for 3.7 and worse for 3.8, but right now it does things no other Python decompiler like
unpyc37
orpycdc
does. For example,decompyle3
handles variable annotations. As always, the issue trackers for the various programs will give you a sense for what needs to be done. For now, I've given up on reporting issues in the other decompilers because there are already enough issues reported, and they are just not getting fixed anyway. -
v3.6.2 Changes
January 05, 2020Yet again the focus has been on just fixing bugs, mostly geared in the
later 3.x range. To get some sense what sill needs fixing, consult
โ test/stdlib/runtests.sh. And that only has a portion of what's known.make_function.py
has gotten so complex that it was split out into 3 parts
to handle different version ranges: Python <3, Python 3.0..3.6 and Python 3.7+.๐ An important fix is that we had been dropping docstrings in Python 3 code as a result
๐ of a incomplete merge from the decompile3 base with respect to the transform phase.Also important (at least to me) is that we can now handle 3.6+
variable type annotations. Some of the decompile3 code uses that in
its source code, and I now use variable annotations in conjunction
with mypy in some of my other Python projectsCode generation for imports, especially where the import is dotted
๐ changed a bit in 3.7; with this release are just now tracking that
๐ change better. For this I've added pseudo instruction
IMPORT_NAME_ATTR
, derived from theIMPORT_NAME
instruction, to
indicate when an import contains a dotted import. Similarly, code for
3.7import .. as
is basically the same asfrom .. import
, the
only difference is the target of the name changes to an "alias" in the
former. As a result, the disambiguation is now done on the semantic
๐ action side, rathero than in parsing grammar rules.๐ Some small specific fixes:
- ๐ 3.7+ some chained compare parsing has been fixed. Other remain.
- ๐ better if/else rule checking in the 3.4 and below range.
- ๐ 3.4+ keyword-only parameter handling was fixed more generally
- ๐ 3.3 .. 3.5 keyword-only parameter args in lambda was fixed