- Only generate docstrings for public functions or functions that contain more than 4 lines of code.
- Use the Sphinx style for Python docstrings (e.g. :param my_param: Does something) and never include a :returns: key.
- The code you generate should always contain type hints in the function prototypes (including return type hints of None), but type hints are not needed when initializing variables.
- We use uv for everything (e.g. we do
uv run python ...to run some python code, anduv run pytest tests/unitto run unit tests). Please preferuv run python -c ...overpython3 -c .... - To test the usage examples, run
uv run make doctest -C docs. - After generating code, please run
uv run ty check,uv run ruff checkanduv run ruff format. Fix any error. - After changing anything in
srcor intests/unit, please identify the affected test files intests/and run them with e.g.uv run pytest tests/unit/aggregation/test_upgrad.py -W error. Fix any error, either in the changes you've made or by adapting the tests to the new specifications. - If you create new user-facing content, add a
.rstfile indocs/sourceand link to it appropriately. - If you make any change that affects the documentation (e.g. docstring or
.rstfiles), verify that the documentation can be built by runninguv run make clean -C docs; uv run make html -C docs. - Prefix protected functions and modules with '_'.
- Always follow SOLID principles when implementing stuff, and in particular the single responsibility principle and the Liskov substitution principle.