|
| 1 | +# pandas Agent Instructions |
| 2 | + |
| 3 | +## Project Overview |
| 4 | +`pandas` is an open source, BSD-licensed library providing high-performance, easy-to-use data structures and data analysis tools for the Python programming language. |
| 5 | + |
| 6 | +## Purpose |
| 7 | +- Assist contributors by suggesting code changes, tests, and documentation edits for the pandas repository while preserving stability and compatibility. |
| 8 | + |
| 9 | +## Persona & Tone |
| 10 | +- Concise, neutral, code-focused. Prioritize correctness, readability, and tests. |
| 11 | + |
| 12 | +## Project Guidelines |
| 13 | +- Be sure to follow all guidelines for contributing to the codebase specified at https://pandas.pydata.org/docs/development/contributing_codebase.html |
| 14 | +- These guidelines are also available in the following local files, which should be loaded into context and adhered to |
| 15 | + - doc/source/development/contributing_codebase.rst |
| 16 | + - doc/source/development/contributing_docstring.rst |
| 17 | + - doc/source/development/contributing_documentation.rst |
| 18 | + - doc/source/development/contributing.rst |
| 19 | + |
| 20 | +## Decision heuristics |
| 21 | +- Favor small, backward-compatible changes with tests. |
| 22 | +- If a change would be breaking, propose it behind a deprecation path and document the rationale. |
| 23 | +- Prefer readability over micro-optimizations unless benchmarks are requested. |
| 24 | +- Add tests for behavioral changes; update docs only after code change is final. |
| 25 | + |
| 26 | +## Type hints guidance (summary) |
| 27 | +- Prefer PEP 484 style and types in pandas._typing when appropriate. |
| 28 | +- Avoid unnecessary use of typing.cast; prefer refactors that convey types to type-checkers. |
| 29 | +- Use builtin generics (list, dict) when possible. |
| 30 | + |
| 31 | +## Docstring guidance (summary) |
| 32 | +- Follow NumPy / numpydoc conventions used across the repo: short summary, extended summary, Parameters, Returns/Yields, See Also, Notes, Examples. |
| 33 | +- Ensure examples are deterministic, import numpy/pandas as documented, and pass doctest rules used by docs validation. |
| 34 | +- Preserve formatting rules: triple double-quotes, no blank line before/after docstring, parameter formatting ("name : type, default ..."), types and examples conventions. |
| 35 | + |
| 36 | +## Pull Requests (summary) |
| 37 | +- Pull request titles should be descriptive and include one of the following prefixes: |
| 38 | + - ENH: Enhancement, new functionality |
| 39 | + - BUG: Bug fix |
| 40 | + - DOC: Additions/updates to documentation |
| 41 | + - TST: Additions/updates to tests |
| 42 | + - BLD: Updates to the build process/scripts |
| 43 | + - PERF: Performance improvement |
| 44 | + - TYP: Type annotations |
| 45 | + - CLN: Code cleanup |
| 46 | +- Pull request descriptions should follow the template, and **succinctly** describe the change being made. Usually a few sentences is sufficient. |
| 47 | +- Pull requests which are resolving an existing Github Issue should include a link to the issue in the PR Description. |
| 48 | +- Do not add summaries or additional comments to individual commit messages. The single PR description is sufficient. |
0 commit comments