GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Python Developer's Guide

This view

  • Original page
  • New address

GeezerVison is showing devguide.python.org — Python Developer’s Guide

Python Developer’s Guide¶

This guide is a comprehensive resource for contributing to Python – for both new and experienced contributors. It is maintained by the same community that maintains Python. We welcome your contributions!

Start with the area that best matches what you want to do. If you still have questions after reviewing the material in this guide, then the Core Python Mentorship group is available to help guide new contributors through the process.

Documentation

Code

Triage

  • Helping with documentation

  • Getting started

  • Style guide

  • reStructuredText primer

  • Translating

  • Helping with the Developer’s Guide

  • Guidelines for using AI tools

  • Setup and building

  • Where to get help

  • Lifecycle of a pull request

  • Running and writing tests

  • Fixing “easy” issues (and beyond)

  • Following Python’s development

  • Git bootcamp and cheat sheet

  • Development cycle

  • Guidelines for using AI tools

  • Using the issue tracker

  • Triaging an issue

  • Helping triage issues

  • Experts index

  • GitHub labels

  • Triage Team

We recommend that sections of this guide be read as needed. You can stop where you feel comfortable and begin contributing immediately without reading and understanding everything. If you do choose to skip around within the guide, be aware that some sections build on each other, so you may need to backtrack for missing concepts or terminology.

For broader open-source contribution advice, a number of individuals from the Python community have contributed to a series of excellent guides at Open Source Guides. For example, How to Contribute to Open Source.

You don’t have to be a compiler engineer to work on Python – Savannah Ostrowski

Quick reference¶

Note

The quick reference documentation has been moved to serve as a cheat-sheet and overview in Getting started.

Go to the new quick reference.

Proposing changes to Python itself¶

Improving Python’s code, documentation and tests are ongoing tasks that are never going to be “finished”, as Python operates as part of an ever-evolving system of technology. An even more challenging ongoing task than these necessary maintenance activities is finding ways to make Python, in the form of the standard library and the language definition, an even better tool in a developer’s toolkit.

While these kinds of change are much rarer than those described above, they do happen and that process is also described as part of this guide:

  • Adding to the stdlib

  • Changing Python

Key resources¶

  • Coding style guides

    • PEP 7 (Style Guide for C Code)

    • PEP 8 (Style Guide for Python Code)

  • Issue tracker

    • Experts index

  • Buildbot status

  • Source code

    • Browse online

    • Download a snapshot of the main branch

  • PEPs (Python Enhancement Proposals)

  • The Python Discourse

  • Where to get help

  • Team log

  • Git bootcamp and cheat sheet

Additional resources¶

  • Anyone can clone the sources for this guide. See Helping with the Developer’s Guide.

  • Help with …

    • CPython’s internals

    • Changing CPython’s grammar

  • Tool support

    • GDB support

    • Sanitizers

    • Various tools with configuration files as found in the Misc/ directory

  • python.org maintenance

Code of conduct¶

Please note that all interactions on Python Software Foundation-supported infrastructure is covered by the PSF Code of Conduct, which includes all infrastructure used in the development of Python itself (for example, Discourse, issue trackers, GitHub, and so on). In general this means everyone is expected to be open, considerate, and respectful of others no matter what their position is within the project.

Other interpreter implementations¶

This guide is specifically for contributing to the Python reference interpreter, also known as CPython (while most of the standard library is written in Python, the interpreter core is written in C and integrates most easily with the C and C++ ecosystems).

There are other Python implementations, each with a different focus. Like CPython, they always have more things they would like to do than they have developers to work on them. Some major examples that may be of interest are:

  • PyPy: A Python interpreter focused on high speed (JIT-compiled) operation on major platforms.

  • GraalPy: A Python interpreter which has first-class support for embedding in Java, built on GraalVM.

  • Jython: A Python interpreter focused on good integration with the Java Virtual Machine (JVM) environment.

  • IronPython: A Python interpreter focused on good integration with the Common Language Runtime (CLR) provided by .NET and Mono.

  • MicroPython: A tiny Python interpreter with small subset of the Python standard library that is optimised to run on microcontrollers and in constrained environments.

  • CircuitPython: A fork of MicroPython designed to simplify experimenting and learning to code on low-cost microcontroller boards.

Full table of contents¶

  • Getting started
    • Quick reference
      • Set up Git
      • Build Python
      • Run the tests
      • Create issues and pull requests
    • Setup and building
      • Install Git
      • Get the source code
      • Compile and build
      • Install dependencies
      • Regenerate configure
      • Regenerate the ABI dump
      • Troubleshoot the build
      • Editors and tools
      • Directory structure
      • Using a container
    • Fixing “easy” issues (and beyond)
    • Git bootcamp and cheat sheet
      • Forking CPython GitHub repository
      • Cloning a forked CPython repository
      • Configure the remotes
      • Listing the remote repositories
      • Setting up your name and email address
      • Enabling autocrlf on Windows
      • Creating and switching branches
      • Deleting branches
      • Renaming branch
      • Staging and committing files
      • Reverting changes
      • Stashing changes
      • Comparing changes
      • Pushing changes
      • Creating a pull request
      • Linking to issues and pull requests
      • Updating your CPython fork
      • Applying a patch to Git
      • Checking out others’ pull requests
      • Accepting and merging a pull request
      • Cancelling an automatic merge
      • Backporting merged changes
      • Editing a pull request prior to merging
      • GitHub CLI
      • Git worktree
    • Lifecycle of a pull request
      • Introduction
      • Step-by-step guide
      • Making good PRs
      • Updating NEWS and What’s New in Python
      • Copyrights
      • Typo fixes
      • patchcheck
      • Making good commits
      • Licensing
      • Submitting
      • Converting an existing patch from b.p.o to GitHub
      • Reviewing
      • Keeping continuous integration green
      • Update branch button
      • Committing/rejecting
      • Crediting
    • Where to get help
      • Discourse
      • Ask #python-dev
      • Core mentorship
      • File a bug
    • Guidelines for using AI tools
      • Considerations for success
      • Acceptable uses
      • Unacceptable uses
      • How these guidelines are applied
  • Development workflow
    • Following Python’s development
      • Standards of behaviour in these communication channels
      • Communicating across cultures and languages
      • Mailing lists
      • Discourse (discuss.python.org web forum)
      • Discord (private chat server)
      • IRC
      • Blogs
      • Setting expectations for open-source participation
      • Additional repositories
    • Changing Python
      • Considerations
      • Suggesting new features and language changes
      • PEP process
    • Development cycle
      • Branches
      • Stages
      • Repository administration
      • Governance
    • Adding to the stdlib
      • Adding to a pre-existing module
      • Adding a new module
      • Adding a new environment variable
    • Standard library extension modules
      • Classifying extension modules
      • Adding an extension module to CPython
    • Changing Python’s C API
      • The internal API
      • Public C API
      • Unstable C API
      • Limited API
    • Changing CPython’s grammar
    • Porting and platform support
      • Ports and contacts
      • Porting to a new platform
  • Issues and triaging
    • Using the issue tracker
      • Reporting an issue
      • Working with issues
      • Disagreement with a resolution
    • Triaging an issue
      • Checklist for triaging
      • Issue fields
      • Helping triage issues
    • GitHub labels
      • Type labels
      • Component labels
      • OS labels
      • Topic labels
      • Version labels
      • Other labels
      • Labels specific to PRs
    • Triage Team
      • Applying the AI policy labels
      • Becoming a member of the Python triage team
  • Documentation
    • Getting started
      • Introduction
      • Building the documentation
    • Helping with documentation
      • Python documentation
      • Helping with documentation issues
      • Translating
      • Proofreading
    • Style guide
      • Footnotes
      • Capitalization
      • Use simple language
      • Charged terminology to avoid
      • Specific words
      • Type names
      • Diátaxis
      • Links
      • Affirmative tone
      • Author attribution
      • Pronunciation of dunder names
      • Economy of expression
      • Security considerations (and other concerns)
      • Code examples
      • Code equivalents
      • Audience
      • Function signatures
    • reStructuredText markup
      • Quick reference
      • reStructuredText primer
      • Typographic conventions
      • Additional markup constructs
    • Translations
      • Translating
      • Coordinating
    • Helping with the Developer’s Guide
      • Developer’s Guide workflow
  • Testing and buildbots
    • Running and writing tests
      • Running
      • Writing
      • Benchmarks
    • Silence warnings from the test suite
    • Increase test coverage
      • Common gotchas
      • Measuring coverage
      • Filing the issue
      • Measuring coverage of C code with gcov and lcov
    • OSS-Fuzz for CPython
      • Adding new targets
    • Working with buildbots
      • In case of trouble
      • Buildbot failures on pull requests
      • Triggering on pull requests
      • Checking results of automatic builds
      • Stability
      • Flags-dependent failures
      • Ordering-dependent failures
      • Transient failures
    • New buildbot workers
      • Preparing for buildbot worker setup
      • Setting up the buildbot worker
      • Buildbot worker operation
      • Required ports
      • Required resources
      • Security considerations
  • Development tools
    • Argument Clinic
      • Background
      • Reference
    • GDB support
      • Page moved
      • CPython tips
    • Sanitizers
      • Available sanitizers
      • Building and testing
      • Suppressing findings
      • Analyzing the output
    • Tools for tracking compiler warnings
      • What to do if a warning check fails GitHub CI
      • Updating the warning ignore file
  • Core team
    • Responsibilities
      • Communication channels and bug notifications
      • Sign a contributor agreement
      • Pull request merging
      • Expectations
    • Accepting pull requests
      • Assessing a pull request
      • Merging the pull request
      • Working with Git
    • Experts index
      • Stdlib
      • Tools
      • Platforms
      • Miscellaneous
      • Experts emeritus
      • Documentation translations
    • Team log
      • Procedure for granting or dropping access
    • Motivations and affiliations
      • Published entries
      • Goals of this page
      • Limitations on scope
    • How to join the core team
      • What it takes
      • Gaining commit privileges
      • Poll template
    • Memorialization
      • Rationale
      • The process
  • Security
    • Security policy
      • What types of bugs are vulnerabilities?
      • What versions of Python accept reports?
      • What to include and how to structure a vulnerability report?
      • How to submit a vulnerability report?
      • When are security fixes released or backported?
      • Code of conduct
      • CVE Numbering Authority (CNA)
    • Python Security Response Team (PSRT)
      • Members
      • Triaging a vulnerability report
      • Remediating a vulnerability report
      • The PSRT bot
      • Handling code signing certificate reports
      • Template responses
      • Members emeritus
    • Software Bill-of-Materials (SBOM)
      • Updating a dependency
      • Adding a new dependency
      • Removing a dependency
  • CPython’s internals
  • Status of Python versions
    • Supported versions
    • Unsupported versions
    • Full chart
    • Status key
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.