Contributing to CPython — Core Concepts

Why contributing to CPython matters

CPython is the reference implementation that defines how Python behaves. When you fix a bug in CPython, every Python user on every platform benefits. When you improve a stdlib module, millions of projects inherit the improvement for free. Few open-source contributions have this much leverage.

Beyond impact, contributing teaches you how a large, multi-decade project operates: code review culture, backwards-compatibility constraints, release management, and consensus-driven governance.

The repository and tools

CPython lives at github.com/python/cpython. Key landmarks:

Path	What it contains
Lib/	Standard library modules (pure Python)
Modules/	C extension modules (e.g., _json, _csv)
Objects/	Core object implementations (int, str, list)
Python/	Interpreter core (compiler, eval loop)
Doc/	reStructuredText documentation
Lib/test/	Test suite
Misc/NEWS.d/	Changelog fragments (blurb format)

Getting started: step by step

1. Sign the CLA. Python requires a Contributor License Agreement. Sign it once at contributors.python.org and it covers all future contributions.

2. Find an issue. Browse github.com/python/cpython/issues and filter by labels like easy, good first issue, or docs. The type-bug and type-feature labels help narrow scope.

3. Build CPython locally.

git clone https://github.com/python/cpython.git
cd cpython
./configure --with-pydebug
make -j$(nproc)

The --with-pydebug flag enables assertions and debug symbols. The resulting binary is ./python.

4. Make your change. Edit the relevant file — a stdlib module in Lib/, a C file in Objects/, or a doc page in Doc/.

5. Write or update tests. Every change needs a test. Run the relevant test module:

./python -m test test_json -v

6. Add a NEWS entry. Use the blurb tool:

pip install blurb
blurb add

This creates a changelog fragment in Misc/NEWS.d/next/.

7. Open a pull request. Push your branch to your fork and open a PR against main. CPython’s CI (GitHub Actions + Buildbot) runs tests on multiple platforms.

The review process

CPython PRs are reviewed by core developers — a group of roughly 100 trusted contributors with merge rights. Reviews can be thorough; expect multiple rounds. Common feedback areas:

• Backwards compatibility. Will this break existing code?
• Performance. Does this slow down a hot path?
• Test coverage. Are edge cases tested?
• Documentation. Is the change reflected in docs?

Do not be discouraged by detailed reviews. They are a sign that the project takes quality seriously, not a rejection of your work.

Contribution types beyond code

Documentation — The Python docs are a critical resource. Fixing typos, clarifying examples, and adding missing sections are always welcome. Doc PRs go through the same review process but are typically faster.

Issue triage — Reproducing reported bugs, adding minimal test cases, and labelling issues helps core developers prioritise. Triage requires no code changes.

Reviewing PRs — Anyone can review. Thoughtful feedback from non-core developers is valued. Focus on correctness, test quality, and documentation.

Common misconception

Many developers believe you need to know C to contribute to CPython. While C knowledge is needed for interpreter internals, the standard library (Lib/) and documentation (Doc/) are pure Python and reStructuredText. Most first contributions touch these areas, not the C codebase.

One thing to remember: The CPython contribution process is designed to be learnable. Thousands of people have made their first open-source contribution here. The community actively mentors newcomers — you just have to show up.