Get ready for release 2.7.0

This commit is contained in:
rocky 2016-07-15 02:50:45 -04:00
parent 0ee52aeeef
commit accc959b71
4 changed files with 114 additions and 8 deletions

View File

@ -1,3 +1,95 @@
2016-07-15 rocky <rb@dustyfeet.com>
* README.rst, uncompyle6/version.py: Get ready for release 2.7.0
2016-07-14 rocky <rb@dustyfeet.com>
* uncompyle6/parser.py, uncompyle6/parsers/parse2.py,
uncompyle6/scanners/scanner2.py, uncompyle6/scanners/scanner26.py,
uncompyle6/semantics/pysource.py: Isolate pseudo op IMPORT_NAME_CONT I think this is a holdover from pre 2.3 days. Possibly it can be
dropped altogether.
2016-07-14 rocky <rb@dustyfeet.com>
* uncompyle6/parsers/parse3.py, uncompyle6/semantics/pysource.py:
Attempt to get 3.5 RETURN_END_IF working This feels hacky and I'm not sure is quite right. Untili we
understand better what to do though, we'll go with it.
2016-07-14 rocky <rb@dustyfeet.com>
* test/Makefile, uncompyle6/semantics/pysource.py: 3.x __qualname__
= supression Class names have become more complicated so the pattern test needs
to be more complex as well. Sigh
2016-07-14 rocky <rb@dustyfeet.com>
* README.rst, uncompyle6/semantics/fragments.py,
uncompyle6/semantics/pysource.py: 3.x list comprehenions
list_if_not, comp_ifnot bug Saw only list_if_not bug, but might also be applicable to comp_ifnot
2016-07-14 rocky <rb@dustyfeet.com>
* test/simple_source/stmts/15_assert.py,
uncompyle6/scanners/scanner3.py: 3.x ""raise AssertionError" vs
"assert" Not sure this is totally correct yet.
2016-07-14 rocky <rb@dustyfeet.com>
* uncompyle6/main.py, uncompyle6/parsers/parse3.py,
uncompyle6/parsers/parse34.py, uncompyle6/scanners/scanner2.py,
uncompyle6/scanners/scanner26.py, uncompyle6/scanners/scanner3.py,
uncompyle6/verify.py: Python 3.4 assertion handling. Improve verify 3.4 has jump optimization like 3.5. verify.py: show mismatch on
verification mismatch
2016-07-13 rocky <rb@dustyfeet.com>
* : Reinstate some code for verification
2016-07-13 rocky <rb@dustyfeet.com>
* uncompyle6/main.py: Back off showing verification errors Pending why this failing in make.
2016-07-13 rocky <rb@dustyfeet.com>
* uncompyle6/semantics/pysource.py: "return None" -> "pass" Python 3.4 classes have what looks like a return None, but this is
invalid syntax. So for now we'll remove all "return None"s. There may be a "pass" in there instead.
2016-07-13 rocky <rb@dustyfeet.com>
* : commit fd0d8d25672b9450bafc1d5c6781bedd7ec8bd1d Author: rocky
<rb@dustyfeet.com> Date: Wed Jul 13 13:00:03 2016 -0400
2016-07-13 rocky <rb@dustyfeet.com>
* test/simple_source/stmts/11_return_val.py,
uncompyle6/semantics/pysource.py: Debugging smutz caused verify
failures
2016-07-12 rocky <rb@dustyfeet.com>
* uncompyle6/parsers/parse3.py, uncompyle6/semantics/fragments.py,
uncompyle6/semantics/pysource.py: Document/correct hide_internal and
store_locals
2016-07-12 rocky <rb@dustyfeet.com>
* test/simple_source/bug33/05_store_locals.py,
test/simple_source/bug33/05_store_name.py,
uncompyle6/semantics/pysource.py: Better 3.2/33 store_locals
handling
2016-07-11 rocky <rb@dustyfeet.com>
* test/simple_source/bug33/05_store_name.py,
test/simple_source/comprehension/05_3x_set_comphension.py,
uncompyle6/parsers/parse3.py, uncompyle6/semantics/pysource.py:
Python 3.2 & 3.3 handle STORE_NAME better
2016-07-11 rocky <rb@dustyfeet.com>
* ChangeLog, NEWS, README.rst, uncompyle6/version.py: Get ready for
release 2.6.2
2016-07-11 rocky <rb@dustyfeet.com>
* test/add-test.py,

7
NEWS
View File

@ -1,3 +1,10 @@
uncompyle6 2.7.0 2016-07-15
- Many Syntax and verifification bugs removed
tested on standard libraries from 2.3.7 to 3.5.1
and they all decompile and verify fine.
I'm sure there are more bugs though.
uncompyle6 2.6.2 2016-07-11 Manhattenhenge
- Extend bytecodes back to 2.3

View File

@ -84,14 +84,21 @@ for usage help.
Known Bugs/Restrictions
-----------------------
Python 2 deparsing decompiles and verifies each and all the Python 2.6.9
to 2.7.11 installed packages I have on my system. Later distributions
average about 200 files. At this point, 2.7 decompilation is
better than uncompyle2. A number of bugs have been fixed.
Python 2 deparsing decompiles and verifies from Python 2.3.7 to Python
3.5.1 on the standard library packages I have on my system.
For Python 3.4.2 bytecode, there is one verification error that needs
addressing. There are still a couple of parse errors on 2.3.7 and
2.4.6. Removing 3.5 verification errors still remains.
(Verification is the process of decompiling bytecode, compiling with a
Python for that byecode version, and then comparing the byetcode
produced by the decompiled/compiled program. Some allowance is made
for inessential differences.)
Later distributions average about 200 files. At this point, 2.7
decompilation is better than uncompyle2. A number of bugs have been
fixed.
That said, I'm sure down the line more problems will turn up. The
decompilation process uses a number of heuristics that may prove
faulty.
There are a few constructs that still need to be added to Python 3.5.
Python 3.6 changes things drastically by using word codes rather than

View File

@ -1,3 +1,3 @@
# This file is suitable for sourcing inside bash as
# well as importing into Python
VERSION='2.6.2'
VERSION='2.7.0'