Go over grammar for why there are duplicate (more) reductions.
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- python
- Domain
- compilers, reverse-engineering
Research direction
Start with ./bin/uncompyle6 -g test/bytecode_2.5/10_if_else_ternary.pyc and compare the reductions with the older Python 2.7 grammar from git history or uncompyle2. Use git bisect to identify when duplicate rules appeared, then inspect the optional and recursive grammar changes and the more specific grammar selection. Done means the duplicate reductions are explained and the affected deparse no longer emits them.
Written by the indexing model from the issue text.
Description
Consider this deparse:
$ ./bin/uncompyle6 -g test/bytecode_2.5/10_if_else_ternary.pyc
# Python bytecode 2.5 (decompiled from Python 2.6)
# Embedded file name: simple_source/branching/10_if_else_ternary.py
...
exprlist ::= expr
compare ::= expr expr COMPARE_OP
compare ::= expr expr COMPARE_OP
cmp ::= compare
cmp ::= compare
expr ::= cmp
expr ::= cmp
...
In the good old days for Python 2.7 this used to be:
compare ::= expr expr COMPARE_OP
cmp ::= compare
expr ::= cmp
I suspect adding various optional nonterminals, e.g. come_from_opt for Python 3.5 is what caused this. And even here, the optional nonterminals were a result of fixing problems before I realized that python 2.7. structure analysis was needed in Python 3.
It is also possible that the duplication comes from changes to use left-recursive grammars. I read in wikipedia that left-recursive grammars for Early parsers generally gives linear parse time, but perhaps I shouldn't believe wikipedia? Or it could be the other way around, maybe I added a right-recursive rule instead of a left-recursive one. (If that's the case we should fix up spark to warn about right, or is it left, recursive rules.)
Tracking this down can be as simple as a git bisect, or reinstating the old 2.7 grammar say from uncompyle2 which should be in git history.
By the way, we now have ways to better select more specific grammars for sets of Python versions, so that could and should be used.
@moagstar is this something that interests you?
- Dominant language
- Python
- Stars
- 4.3k
- Forks
- 463
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rocky/python-uncompyle6
-
Works on decompyle3
Difficulty 4/5 3-5 days Newbie friendliness 35/100
rocky/python-uncompyle6#506 · 1 comment ·
-
Python 3.8 Volunteer wanted Works on decompyle3
Difficulty 4/5 3-5 days Newbie friendliness 35/100
rocky/python-uncompyle6#492 · 4 comments ·
-
Redundant "else:" OpenControl Flow Python 3.8 Volunteer wanted Works on decompyle3
Difficulty 4/5 3-5 days Newbie friendliness 45/100
rocky/python-uncompyle6#486 ·
-
Missing "While True" OpenControl Flow Python 3.8 Volunteer wanted Works on decompyle3
Difficulty 4/5 3-5 days Newbie friendliness 45/100
rocky/python-uncompyle6#485 · 4 comments ·
-
Duplicate Python 3.9+
Difficulty 5/5 Over a week Newbie friendliness 25/100
rocky/python-uncompyle6#484 · 9 reactions ·
All issues in rocky/python-uncompyle6
Similar issues
-
area: harness bug status: needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Human-Agent-Society/reef#625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 80/100
learningequality/kolibri#15351 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Name consistency Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
eellak/triplestore#65 · 1 comment ·