Summary
While reviewing transcrypt/modules/org/transcrypt/, I noticed two files that closely mirror the main compiler but don't appear to be referenced anywhere in the codebase: compiler1.py and compiler38.py (each ~164KB, ~4,000 lines).
Investigation
Only compiler.py is imported at runtime:
$ grep -n "^from|^import" transcrypt/main.py | grep -i compil
from org.transcrypt import compiler
And a repo-wide search turns up no references to the other two:
$ grep -rln "compiler1|compiler38" --include=.py --include=.cfg --include=.in --include=.txt .
(no results)
Neither file appears in setup.py or MANIFEST.in as a distinct entry point either.
Evidence they've drifted from the maintained file
Because they're never exercised, compiler1.py and compiler38.py have fallen out of sync with compiler.py. One concrete example — compiler.py (line 96) has a guard the other two lack:
compiler.py
self.optionsChanged = project and utils.commandArgs.projectOptions != project.get('options')
compiler1.py / compiler38.py (identical in both)
self.optionsChanged = utils.commandArgs.projectOptions != project.get('options')
There are also larger structural differences in visit_Assign, around handling ast.Index / ast.ExtSlice (older Python AST shapes) vs. ast.Slice in compiler.py — this suggests compiler1.py/compiler38.py may be legacy per-Python-version forks that predate a later consolidation into compiler.py.
Why this seemed worth flagging
If these files are intentionally kept — e.g. for reference, rollback, or supporting an older Python version — that's completely reasonable. But as they stand, they're visually indistinguishable from live code to a new contributor, and a fix landed in compiler.py (like the guard above) gives no signal about whether the same fix is still needed, or already irrelevant, in the other two.
Questions
- Are compiler1.py / compiler38.py still needed for something (e.g. older Python version support), or are they safe to delete?
- If they're intentionally kept, would a short comment at the top of each file (or a note in CONTRIBUTING) explaining their purpose be welcome?
Happy to submit a small PR for either outcome — deletion or documentation — once I know which direction is preferred.
Summary
While reviewing transcrypt/modules/org/transcrypt/, I noticed two files that closely mirror the main compiler but don't appear to be referenced anywhere in the codebase: compiler1.py and compiler38.py (each ~164KB, ~4,000 lines).
Investigation
Only compiler.py is imported at runtime:
$ grep -n "^from|^import" transcrypt/main.py | grep -i compil
from org.transcrypt import compiler
And a repo-wide search turns up no references to the other two:
$ grep -rln "compiler1|compiler38" --include=.py --include=.cfg --include=.in --include=.txt .
(no results)
Neither file appears in setup.py or MANIFEST.in as a distinct entry point either.
Evidence they've drifted from the maintained file
Because they're never exercised, compiler1.py and compiler38.py have fallen out of sync with compiler.py. One concrete example — compiler.py (line 96) has a guard the other two lack:
compiler.py
self.optionsChanged = project and utils.commandArgs.projectOptions != project.get('options')
compiler1.py / compiler38.py (identical in both)
self.optionsChanged = utils.commandArgs.projectOptions != project.get('options')
There are also larger structural differences in visit_Assign, around handling ast.Index / ast.ExtSlice (older Python AST shapes) vs. ast.Slice in compiler.py — this suggests compiler1.py/compiler38.py may be legacy per-Python-version forks that predate a later consolidation into compiler.py.
Why this seemed worth flagging
If these files are intentionally kept — e.g. for reference, rollback, or supporting an older Python version — that's completely reasonable. But as they stand, they're visually indistinguishable from live code to a new contributor, and a fix landed in compiler.py (like the guard above) gives no signal about whether the same fix is still needed, or already irrelevant, in the other two.
Questions
Happy to submit a small PR for either outcome — deletion or documentation — once I know which direction is preferred.