run_exercise.py: why run_name='__main__', and should RUNNABLE auto-register?

[dab00gieman]

The runner in answers/run_exercise.py does:

runpy.run_path(str(path), run_name="__main__")

and hardcodes:

RUNNABLE = {
    "4": "exercise4/answer.py",
    "5": "exercise5/answer.py",
    "6": "exercise6/answer.py",
    "7": "exercise7/answer.py",
    "guess": "guess-game.py",
    "todo": "to-do manager.py",
}

Two questions: (1) Is run_name="__main__" there specifically so if __name__ == "__main__": guards in the target files fire — and would the games misbehave without it? (2) As answers/ grows (the quest has ~100 files), would you auto-register directories instead of maintaining the dict by hand, or is the explicit dict a deliberate curated list of what's actually runnable?

[mgkvibez]

Why run_name="__main__": runpy.run_path executes the file in a fresh namespace, and by default sets that namespace's __name__ to the path string ("answer.py" or similar) — not "__main__". That means any if __name__ == "__main__": guard in the target file would never fire, and scripts that rely on the guard (plus anything that checks __main__ semantics) would print nothing. Passing run_name="__main__" makes the file behave exactly as if you'd typed python answers/exercise4/answer.py — which is the whole point of a runner. (One side effect to know: if the target file doesn't guard its top-level prints, they run either way — run_name only matters for guarded code and __main__ checks.)

Should RUNNABLE auto-register? Yes, trivially, and it removes the "added exercise 8, forgot the runner" failure mode:

RUNNABLE = {
    p.parent.name.removeprefix("exercise"): str(p.relative_to(ANSWERS))
    for p in sorted(ANSWERS.glob("exercise*/answer.py"))
}
RUNNABLE.update({
    "guess": "guess-game.py",
    "todo": "to-do manager.py",
})

The trade-off: the explicit dict is a curated list (stable keys, only things you're confident run cleanly); globbing is everything that matches (half-finished answers become runnable with ugly tracebacks). Given this repo's answers are one-file scripts that always print, globbing is safe here — the [x]-style existence markers in your list output already communicate the "might be broken" caveat. Keep list as the safety valve and auto-register is strictly better.