Here are the basic steps needed to get set up and open a pull request.
This is meant as a checklist and cheat-sheet, not a comprehensive guide. For complete instructions see the
and the
.
Set up Git
Install and set up Git.
For detailed setup information, see
. There is also a more detailed
.
Fork and clone the repo
Fork
to your GitHub account and clone the repo using:
gitclonehttps://github.com/<your_username>/cpythoncdcpythonFor detailed information, see
.
Build Python
Unix
./configure--config-cache--with-pydebug&&make-j$(nproc)macOS
./configure--config-cache--with-pydebug&&make-j$(sysctl-nhw.logicalcpu)Windows
PCbuild\build.bat -e -d See also
,
how to install and build dependencies
, and the platform-specific pages for
,
, and
.
Run the tests
Unix
./python-mtest-j0 macOS
./python.exe-mtest-j0 Note
macOS systems use ./python.exe in order to avoid filename conflicts with the Python directory.
Windows
.\python.bat -m test -j0 See also
.
Create issues and pull requests
Create issues for nontrivial changes
For most changes,
before submitting a pull request. Trivial changes like typo fixes do not need issues.
Create work branches
Work on a feature or fix in a new branch in Git from the main branch:
gitcheckout-bfix-issue-12345mainMake changes, then
and
.
Document your changes
Many changes deserve a NEWS entry which documents what changed. For more information on how and when to write news entries, see
“Updating NEWS and What’s New in Python”
.
A news entry can be created locally with the
tool and its blurbadd command or online after a pull request has been opened with
.
For more information about how to create news entries, see
.
Create pull requests
Create pull requests on GitHub from your branches, on your fork, and make sure to put the relevant issue number in gh-NNNNNN format in the pull request title. For example:
gh-12345: Fix some bug in spam module See also, GitHub’s documentation on
.
For more detailed guidance, follow the
step-by-step pull request guide
.
Note
First time contributors will need to sign the Contributor Licensing Agreement (CLA) as described in the
section of this guide.
Work on your pull request
Make sure the
continuous integration checks on your pull request are green
(successful).
Read and respond to reviewer comments on your pull request.
See also, GitHub’s documentation on
.
Don’t force-push
In order to keep the commit history intact, avoid squashing or amending history and then force-pushing to the PR. Reviewers often want to look at individual commits.
CPython uses squash merges, so PRs will end up as single commits when merged.