One of the ways that this decompiler is different from most of the others I've seen is in its extensive testing.
After a lot of experimentation, the most effective way to do this is to write a little Python test program for a particular feature you want to test decomplation on. For example, suppose I want to see
if the Python 3 format strings of the form f'{xxx}' and f'{xxx!s}' are handled correctly.
First I'll write come code using asserts. Like this:
abc = 'def'
assert 'defdef' == f'{abc}{abc!s}'
Above it is pretty easy to figure out the assert statement. But in many cases it is too difficult for me to do, so I will let Python do the work for me instead:
abc = 'def'
print(f'{abc}{abc!s}')
After running this, Python will tell me what the right result is.
Next put the test somwhere under test/simple_source. Let's say you are using Python 3.6 and this is a bug in version 3.6 or later. (Format specifiers were added around Python 3.6). Here, test/simple_source/bug36 might be a good directory to add this under.
The number at the front of the test-case names is just to influence where in the testing the test should be. Simple and fast tests start 01 and very complicated ones start with a high number like 10. That way when testing, we do the easy cases before the difficult one.
Next cd test; ./add-test.py --run simple-source/bug36/01_fstring.py This will compile the test and add it to the corresponding bytecode_N.N_run directory. Here N.N would be 3.6.
Add the test into git using git add simple_source/bug36/01_fstring.py and git add -f tests/bytecode-3.6-run/01_fstring.py.
Finally to test run make check-bytecode-3.6.
Here is what this does. Whenever you run make check and you are running a Python 3.6 interpreter,
- the bytecode in
test/bytecode_3.6_runis decompiled - the decompiled bytecode is run to make sure not only is the program syntactically correct, but that the code work in the ways that the asserts check.