- The runner:
runner.pydynamically imports every module underultimatepythonand runs any callable namedmainwith zero parameters. Keepmain()functions parameterless, idempotent, and side-effect safe for CI. - Single-file runs are supported: modules are runnable with
python ultimatepython/<category>/<module>.py. Most modules already includeif __name__ == "__main__": main(). - Examples use plain Python stdlib only. Avoid adding new third-party dependencies without updating
requirements.txtandpyproject.toml. - Assertions are used as the primary verification mechanism inside examples (not pytest tests). Preserve their intent and messages when editing.
- main() contract: must be a function, accept zero parameters, and not raise exceptions when run. The runner asserts the function is callable and has zero parameters. Example:
ultimatepython/syntax/function.pyandultimatepython/classes/basic_class.py. - Module structure: brief module docstring, helper functions/classes, then
main()demonstrating usage via asserts, and finalif __name__ == "__main__": main(). - Avoid long-running or destructive operations in examples. If a module interacts with the filesystem (e.g.,
advanced/file_handling.py), keep operations local to ephemeral files (module uses_TARGET_FILE = "sample.txt"), and clean up after running. - Typing: some modules include simple type hints; prefer to keep existing style and minimal typing additions only.
- Formatting & linting: the repo uses
ruffandisortsettings inpyproject.toml. Try to keep line-length <= 160 and maintain import ordering consistent with isort defaults.
- Preserve the didactic nature: keep explanatory comments and short, clear examples.
- If you add new modules, include them under the appropriate folder and follow the same pattern (module docstring, helpers,
main(),if __name__...). The runner will pick them up automatically. - If a change requires a new dependency, add it to
requirements.txtand updatepyproject.tomlbefore proposing a PR.
- The top-level
README.mdis the primary project landing page: it explains the repo goals, running instructions, and links to example modules (it also shows badges for CI and coverage). When changing top-level documentation, keep the runner guidance intact (it points torunner.py) and preserve any badges and links. - Translated files like
README.ko.md,README.zh_tw.md,README.es.md,README.de.md,README.fr.md, andREADME.hi.mdare language variants of the same content. If you update the EnglishREADME.md, consider updating translations or add a brief note in the PR explaining why translations were not updated.
- Run all examples locally (fast smoke):
python runner.py- Run a single example (recommended when editing):
python ultimatepython/syntax/function.py- Check formatting/linting (ruff/isort configured in
pyproject.toml): run your local ruff/isort commands or CI. - Coverage config exists in
pyproject.toml(coverage fail_under=80). The examples use assertions; runningrunner.pyis a good quick coverage smoke.
- CI expects that running
runner.pyand executing eachmain()will succeed. Avoid adding code that requires network access, long sleeps, or interactive input. - Do not introduce external services or config files; this repo intentionally uses only the Python standard library.
runner.py— how modules are discovered and executed (pkgutil.walk_packages +mainlookups).ultimatepython/syntax/*.py— simple, illustrative examples of themain()pattern.ultimatepython/advanced/*— more involved examples; watch for filesystem or concurrency code (e.g.,advanced/file_handling.py,advanced/async.py).pyproject.toml— linting/format settings and coverage rules.
If anything in these instructions is unclear or you want additional examples (CI commands, recommended local dev Docker container, or a tiny unit-test harness), tell me which areas to expand and I'll iterate.