THEME color block in moon_engine.py: zero references, tests pass without it — but why is it here?

[XEDAB]

There's a 15-color theme block at the top of moon_engine.py (lines 45–60: BG/ACC/GOLD/TEXT… under a # ── THEME ── comment).

I grepped the whole repo for these names — bare references, moon_engine.<name> attribute access, imports, even the hex values themselves — zero references anywhere. Then I commented the block out and ran the test suite: all 24 tests pass. So removing it breaks nothing.

I'll admit these color blocks are BEAUTIFUL, but I'm curious why they're living in a backend engine module instead of the web front-end. Leftover from something? Could they be cleaned up, or moved somewhere they'd actually be used?

[LeyckerS]

You are right on all three counts, and the answer to "why is it here" is archaeology rather than design.

moon_engine.py used to be a generated file. The history:

43114d5  refactor: gen_1.py -> moon_tk.py, and the engine regenerated from it
f2af536  engine: moon_engine.py is the source now, not a generated file
5f172d3  chore: delete the tkinter GUI and its generator

There was a tkinter GUI, moon_tk.py, and a build_engine.py that produced moon_engine.py from it by stripping the interface. That block is the tkinter colour palette — BG, SURFACE, BORDER, TEXT, OK, ERR are Tk widget colours, and the generator carried the module-level constants across wholesale because separating "engine" from "interface" by transformation is imprecise at the edges.

Then moon_engine.py became the source of truth in its own right, and moon_tk.py and the generator were deleted. The palette stayed because by then it was simply part of the file. None of the three exist any more:

$ ls moon_tk.py build_engine.py start_tk.bat
  nothing

The GUI that replaced it is web/styles.css, which has its own palette in CSS custom properties and shares not one hex value with this block.

So: delete it. Your check was the right one and it is complete — no bare references, no attribute access, no imports, no hex-value matches, and the suite passes without it. There is no consumer to break because the consumer was deleted in 5f172d3.

Worth knowing that this is the second find of exactly this shape: Engine._LOG_MAX_LINES (#80) is a constant defined once and read nowhere, left over from an earlier logging design. Both are residue from the generated-file era. If you find yourself curious, a sweep of moon_engine.py for other module-level names with zero references would be a reasonable follow-up issue — but keep it separate from this one.

Labelled good first issue: it is a deletion with the reasoning already written down here, and the pull request needs nothing more than the diff plus a line saying the suite still passes.

Take it yourself if you want it — you did the work of finding it. If you would rather leave it for someone new, say so and I will hold it as a first contribution.

[XEDAB]

You are right on all three counts, and the answer to "why is it here" is archaeology rather than design.

moon_engine.py used to be a generated file. The history:

43114d5  refactor: gen_1.py -> moon_tk.py, and the engine regenerated from it
f2af536  engine: moon_engine.py is the source now, not a generated file
5f172d3  chore: delete the tkinter GUI and its generator

There was a tkinter GUI, moon_tk.py, and a build_engine.py that produced moon_engine.py from it by stripping the interface. That block is the tkinter colour palette — BG, SURFACE, BORDER, TEXT, OK, ERR are Tk widget colours, and the generator carried the module-level constants across wholesale because separating "engine" from "interface" by transformation is imprecise at the edges.

Then moon_engine.py became the source of truth in its own right, and moon_tk.py and the generator were deleted. The palette stayed because by then it was simply part of the file. None of the three exist any more:

$ ls moon_tk.py build_engine.py start_tk.bat
  nothing

The GUI that replaced it is web/styles.css, which has its own palette in CSS custom properties and shares not one hex value with this block.

So: delete it. Your check was the right one and it is complete — no bare references, no attribute access, no imports, no hex-value matches, and the suite passes without it. There is no consumer to break because the consumer was deleted in 5f172d3.

Worth knowing that this is the second find of exactly this shape: Engine._LOG_MAX_LINES (#80) is a constant defined once and read nowhere, left over from an earlier logging design. Both are residue from the generated-file era. If you find yourself curious, a sweep of moon_engine.py for other module-level names with zero references would be a reasonable follow-up issue — but keep it separate from this one.

Labelled good first issue: it is a deletion with the reasoning already written down here, and the pull request needs nothing more than the diff plus a line saying the suite still passes.

Take it yourself if you want it — you did the work of finding it. If you would rather leave it for someone new, say so and I will hold it as a first contribution.

Thanks for the offer — and for the archaeology lesson, it explains everything. I half-expected it to be some eldritch, cursed code — the kind that looks safe to delete in theory but blows up in practice. Turns out it was just history. I'll pass this one on to a new contributor, it's a perfect first issue.

[AashishGupta2007]

@LeyckerS I have understood the history from the thread, and I will verify independently before submitting. Please assign me this.

[LeyckerS]

@AashishGupta2007 — yours, assigned. Verifying independently before submitting is the right instinct and it is the house rule; the thread gives you the why, not permission to skip the check.

@XEDAB — thank you for offering it up, and I am going to overrule you slightly, for a reason worth stating.

The beginner tier is not short of work. #79, #80 and #93 are all reserved for people who have never had a pull request merged anywhere, and all three are still unclaimed — a fourth held issue would not attract anybody, it would just sit. Meanwhile @AashishGupta2007 asked for this one directly. An issue held for a hypothetical newcomer while a real contributor waits is worse for everyone.

Your instinct was generous and I would rather have it than not. It is just that supply is not the constraint here.

And "I half-expected it to be some eldritch, cursed code" is the correct default. The reason the archaeology was worth doing is that a dead-looking block is sometimes load-bearing through something no grep finds — a globals() lookup, a name exported by a wildcard import, a string built at runtime. Here it genuinely was not, and the history said why rather than leaving us to trust that four different searches all came back empty. That habit is what makes a deletion safe rather than lucky.

[LeyckerS]

Fixed by #159, merged — thanks @AashishGupta2007.

The block is gone. For the record, since this issue asked why it was there rather than just whether it was dead, both halves of the answer are now known:

Why it was unused: the live interface takes its colours from CSS custom properties in web/styles.css, and not one of the fifteen hex values in the Python block appears there. Checked all fifteen.

Why it existed at all: moon_engine.py was once generated from a tkinter GUI.

5f172d3  chore: delete the tkinter GUI and its generator
43114d5  refactor: gen_1.py -> moon_tk.py, and the engine regenerated from it

The palette belonged to that GUI and was compiled into the engine along with everything else. 5f172d3 deleted the generator and its source but not its output, so the block outlived both. That is the general rule for this file: a module-level constant here with zero references is usually residue from the generated era rather than something added and forgotten, and git log --all -- moon_tk.py build_engine.py is the fastest way to confirm it.

In v4.1 when it ships; on main now.