The scheme for turning 2.6 bytecode into 2.7 psuedo bytecode
I think is a lose.
I won't work for fragment handling.
Instead, change the grammar and syntax rules
This also has the benefits:
* We see how code generation changed over releases
by looking at grammar and semantic rules rather
than arbitrary code
* We can better assocate with what's running
(in a sense this is a restatement of broken fragment
handling)
* With the right structure in place we are in a better position to
handle 2.5, 2.4, etc. That is, after a while, the incremental changes
to get say from python 2.3 bytecode to python 2.7 are great.
Conflicts:
uncompyle6/parsers/astnode.py
Don't try to convert 2.6 bytecode to 2.7 psuedo bytecode.
Instead adjust grammar and semantic actions.
Down the line we should to segregate version changes in
semantic code better.
* parse3.py Had botched if-for-else test by grammar addition
* semantics/*.py: Show errorstack in failed parse when -g (requires sparck 1.2.0)
* some optimization in scanner3
problem was handling in Python 3.2
for ...
if ...
else:
....
jump for
come from if
jump for
In later Python 3's a "come from" is removed.
Also, start to DRY parser{,2,3} grammar rules.
parse{2,3,r}.py: DRY Python expressions between Python 2 and 3
pysource.py, fragment.py, parser.py: handle long lists by grouping in chunks of 32
and 256
bin/uncompyle6: count %s properly
better and make more similar to Python3
load.py: handle magic errors better
main.py: correct use when passing a .py instead of a .pyc better and a message
err when file not found.
pysource.py: fix up main docstring; code moved from main.py
exception errrors such as when a pyc file is not found
uncompyle6: Hook in --grammar option to showing grammar.
rules. Default now does not show timestamp.
