|
| 1 | +# libtmux Python Project Rules |
| 2 | + |
| 3 | +<project_stack> |
| 4 | +- uv - Python package management and virtual environments |
| 5 | +- ruff - Fast Python linter and formatter |
| 6 | +- py.test - Testing framework |
| 7 | + - pytest-watcher - Continuous test runner |
| 8 | +- mypy - Static type checking |
| 9 | +- doctest - Testing code examples in documentation |
| 10 | +</project_stack> |
| 11 | + |
| 12 | +<coding_style> |
| 13 | +- Use a consistent coding style throughout the project |
| 14 | +- Format code with ruff before committing |
| 15 | +- Run linting and type checking before finalizing changes |
| 16 | +- Verify tests pass after each significant change |
| 17 | +</coding_style> |
| 18 | + |
| 19 | +<python_docstrings> |
| 20 | +- Use reStructuredText format for all docstrings in src/**/*.py files |
| 21 | +- Keep the main description on the first line after the opening `"""` |
| 22 | +- Use NumPy docstyle for parameter and return value documentation |
| 23 | +- Format docstrings as follows: |
| 24 | + ```python |
| 25 | + """Short description of the function or class. |
| 26 | + |
| 27 | + Detailed description using reStructuredText format. |
| 28 | + |
| 29 | + Parameters |
| 30 | + ---------- |
| 31 | + param1 : type |
| 32 | + Description of param1 |
| 33 | + param2 : type |
| 34 | + Description of param2 |
| 35 | + |
| 36 | + Returns |
| 37 | + ------- |
| 38 | + type |
| 39 | + Description of return value |
| 40 | + """ |
| 41 | + ``` |
| 42 | +</python_docstrings> |
| 43 | + |
| 44 | +<python_doctests> |
| 45 | +- Use narrative descriptions for test sections rather than inline comments |
| 46 | +- Format doctests as follows: |
| 47 | + ```python |
| 48 | + """ |
| 49 | + Examples |
| 50 | + -------- |
| 51 | + Create an instance: |
| 52 | + |
| 53 | + >>> obj = ExampleClass() |
| 54 | + |
| 55 | + Verify a property: |
| 56 | + |
| 57 | + >>> obj.property |
| 58 | + 'expected value' |
| 59 | + """ |
| 60 | + ``` |
| 61 | +- Add blank lines between test sections for improved readability |
| 62 | +- Keep doctests simple and focused on demonstrating usage |
| 63 | +- Move complex examples to dedicated test files at tests/examples/<path_to_module>/test_<example>.py |
| 64 | +- Utilize pytest fixtures via doctest_namespace for complex scenarios |
| 65 | +</python_doctests> |
| 66 | + |
| 67 | +<testing_practices> |
| 68 | +- Run tests with `uv run py.test` before committing changes |
| 69 | +- Use pytest-watcher for continuous testing: `uv run ptw . --now --doctest-modules` |
| 70 | +- Fix any test failures before proceeding with additional changes |
| 71 | +</testing_practices> |
| 72 | + |
| 73 | +<git_workflow> |
| 74 | +- Make atomic commits with conventional commit messages |
| 75 | +- Start with an initial commit of functional changes |
| 76 | +- Follow with separate commits for formatting, linting, and type checking fixes |
| 77 | +</git_workflow> |
0 commit comments