All contributions, bug reports, bug fixes, documentation improvements, enhancements and ideas are welcome.
The GitHub "issues" tab contains some issues labeled "Good as first PR"; Look those up if you're looking for a quick way to help out.
Please include a short, self-contained Python snippet reproducing the problem. You can have the code formatted nicely by using GitHub Flavored Markdown :
```python print("I ♥ pandas!") ```
Include the full version string of pandas and it's dependencies. In recent (>0.12) versions of pandas you can use a built in function:
>>> from pandas.util.print_versions import show_versions >>> show_versions()
and in 0.13.1 onwards:
Explain what the expected behavior was, and what you saw instead.
- Make sure the test suite passes on your box, Use the provided
test_*.shscripts or tox.
- Use proper commit messages:
- a subject line with
- One blank line.
- Optionally, a commit message body.
- a subject line with
- Please reference relevant Github issues in your commit message using
#1234. Either style is fine but the '#' style generates noise when your rebase your PR.
doc/source/vx.y.z.txtcontains an ongoing changelog for each release. Add an entry to this file as needed in your PR: document the fix, enhancement, or (unavoidable) breaking change.
- Keep style fixes to a separate commit to make your PR more readable.
- An informal commit message format is in effect for the project. Please try
and adhere to it. Check
git logfor examples. Here are some common prefixes along with general guidelines for when to use them:
- ENH: Enhancement, new functionality
- BUG: Bug fix
- DOC: Additions/updates to documentation
- TST: Additions/updates to tests
- BLD: Updates to the build process/scripts
- PERF: Performance improvement
- CLN: Code cleanup
- Maintain backward-compatibility. Pandas has lots of users with lots of existing code. Don't break it.
- If you think breakage is required clearly state why as part of the PR.
- Be careful when changing method signatures.
- Add deprecation warnings where needed.
- Performance matters. Make sure your PR hasn't introduced perf regressions by using
- Docstrings follow the numpydoc format.
- Write tests.
- When writing tests, use 2.6 compatible
self.assertFoomethods. Some polyfills such as
assertRaisescan be found in
- Do not attach doctrings to tests. Make the test itself readable and use comments if needed.
- Generally, pandas source files should not contain attributions. You can include a "thanks to..."
in the release changelog. The rest is
- When you start working on a PR, start by creating a new branch pointing at the latest commit on github master.
- Do not merge upstream into a branch you're going to submit as a PR.
git rebaseagainst the current github master.
- For extra brownie points, you can squash and reorder the commits in your PR using
git rebase -i. Use your own judgment to decide what history needs to be preserved. If git frightens you, that's OK too.
assertunless you want the assertion stripped by
- The pandas copyright policy is detailed in the pandas LICENSE.
- On the subject of PEP8: yes.
- We've written a tool to check that your commits are PEP8 great,
pip install pep8radius. Look at PEP8 fixes in your branch vs master with
pep8radius master --diffand make these changes with
pep8radius master --diff --in-place.
- On the subject of a massive PEP8-storm touching everything: not too often (once per release works).