|
7 | 7 | - Examples use plain Python stdlib only. Avoid adding new third-party dependencies without updating `requirements.txt` and `pyproject.toml`. |
8 | 8 | - Assertions are used as the primary verification mechanism inside examples (not pytest tests). Preserve their intent and messages when editing. |
9 | 9 |
|
10 | | -## Patterns and conventions to follow |
| 10 | +## Patterns and conventions |
11 | 11 |
|
12 | | -- 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.py` and `ultimatepython/classes/basic_class.py`. |
13 | | -- Module structure: brief module docstring, helper functions/classes, then `main()` demonstrating usage via asserts, and final `if __name__ == "__main__": main()`. |
14 | | -- 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. |
15 | | -- Typing: some modules include simple type hints; prefer to keep existing style and minimal typing additions only. |
16 | | -- Formatting & linting: the repo uses `ruff` and `isort` settings in `pyproject.toml`. Try to keep line-length <= 160 and maintain import ordering consistent with isort defaults. |
| 12 | +- `main()` must be parameterless and not raise exceptions when run. Examples: `ultimatepython/syntax/function.py`, `ultimatepython/classes/basic_class.py`. |
| 13 | +- Module structure: docstring, helpers, `main()` demonstrating usage via asserts, `if __name__ == "__main__": main()`. |
| 14 | +- Avoid long-running or destructive operations. For filesystem interactions, keep them local to ephemeral files and clean up after running. |
| 15 | +- Use `ruff` and `isort` (configured in `pyproject.toml`) for consistency with existing modules. |
17 | 16 |
|
18 | | -## When creating or modifying modules |
| 17 | +## Before committing |
19 | 18 |
|
20 | | -- Preserve the didactic nature: keep explanatory comments and short, clear examples. |
21 | | -- 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. |
22 | | -- If a change requires a new dependency, add it to `requirements.txt` and update `pyproject.toml` before proposing a PR. |
| 19 | +- New modules go under the appropriate folderβthe runner discovers them automatically. |
| 20 | +- If a change requires a new dependency, update `requirements.txt` and `pyproject.toml`. |
| 21 | +- When updating `README.md`, consider updating translations or note why they were skipped. |
23 | 22 |
|
24 | | -## Top-level README files |
| 23 | +## Quick reference |
25 | 24 |
|
26 | | -- The top-level `README.md` is 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 to `runner.py`) and preserve any badges and links. |
27 | | -- Translated files like `README.ko.md`, `README.zh_tw.md`, `README.es.md`, `README.de.md`, `README.fr.md`, and `README.hi.md` are language variants of the same content. If you update the English `README.md`, consider updating translations or add a brief note in the PR explaining why translations were not updated. |
28 | | - |
29 | | -## Developer workflows and useful commands |
30 | | - |
31 | | -- Run all examples locally (fast smoke): |
32 | | - |
33 | | -```bash |
34 | | -python runner.py |
35 | | -``` |
36 | | - |
37 | | -- Run a single example (recommended when editing): |
38 | | - |
39 | | -```bash |
40 | | -python ultimatepython/syntax/function.py |
41 | | -``` |
42 | | - |
43 | | -- Check formatting/linting (ruff/isort configured in `pyproject.toml`): run your local ruff/isort commands or CI. |
44 | | -- Coverage config exists in `pyproject.toml` (coverage fail_under=80). The examples use assertions; running `runner.py` is a good quick coverage smoke. |
| 25 | +- Run all examples: `python runner.py` |
| 26 | +- Run single example: `python ultimatepython/<category>/<module>.py` |
| 27 | +- Coverage target: 80% (in `pyproject.toml`) |
45 | 28 |
|
46 | 29 | ## Integration points & CI notes |
47 | 30 |
|
48 | 31 | - CI expects that running `runner.py` and executing each `main()` will succeed. Avoid adding code that requires network access, long sleeps, or interactive input. |
49 | 32 | - Do not introduce external services or config files; this repo intentionally uses only the Python standard library. |
50 | 33 |
|
51 | | -## Files and locations of interest (examples to inspect) |
52 | | - |
53 | | -- `runner.py` β how modules are discovered and executed (pkgutil.walk_packages + `main` lookups). |
54 | | -- `ultimatepython/syntax/*.py` β simple, illustrative examples of the `main()` pattern. |
55 | | -- `ultimatepython/advanced/*` β more involved examples; watch for filesystem or concurrency code (e.g., `advanced/file_handling.py`, `advanced/async.py`). |
56 | | -- `pyproject.toml` β linting/format settings and coverage rules. |
| 34 | +## Key files |
57 | 35 |
|
58 | | -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. |
| 36 | +- `runner.py` β discovery and execution (pkgutil.walk_packages + `main` lookups) |
| 37 | +- `pyproject.toml` β formatting, linting, coverage rules |
0 commit comments