compiler1.py / compiler38.py appear to be dead code that has drifted from compiler.py (including missing bugfixes) — should be removed or clarified

Start by reviewing transcrypt/modules/org/transcrypt/compiler.py alongside compiler1.py and compiler38.py, then verify the references in transcrypt/main.py, setup.py, and MANIFEST.in. Confirm with maintainers whether the two files support an older Python version or another workflow; done means either removing the unused files or documenting their purpose and keeping them intentionally.

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

1. Are compiler1.py / compiler38.py still needed for something (e.g. older Python version support), or are they safe to delete?
2. 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.