Development Tools

SVN Tree

The Python source code is stored in the Subversion, or SVN, version control system.

Anyone can check out a read-only copy of the source tree by using anonymous SVN. To check out the tree:

svn co python

Running svn update will update the tree to the most recent version. Checkin messages and the accompanying diffs are sent to the python-checkins mailing list so that they get double-checked by the other developers. It's recommended that you subscribe to this list, especially if you've been granted write access to the source tree.

For information about SVN, see "Version Control with Subversion" at

Check-in Policies

Write access to the Python SVN tree is not automatically granted, though there's no formal process to go through to get it. If the python-dev team knows who you are, whether through mailing list discussion, having submitted patches, or some other interaction, then you can ask for full SVN access. You'll need to have an SSH key, and provide it with your request.

If you're granted SVN write access, you have to follow a few simple rules.

  • Use the patch manager to submit your first two or three patches for review before you commit, unless specifically instructed otherwise.

  • Before making a code change, make sure you've checked out the most current version.

  • Before checking in a code change, re-run the entire Python test suite to be sure that you haven't broken anything. To run the complete test suite, use the following command from the top directory of the source tree:

    ./python ./Lib/test/

    If the module you're modifying doesn't have a test suite, you could consider writing a set of test cases for it.

  • When fixing a bug, you should add a test case to the test suite located in Lib/test/ that would have caught this bug. When adding a whole new class or module, you should add a set of tests for it.

  • If a change affects OS-dependent behavior, run your tests on as many OSes as you have easy access to. For additional testing, see the Python Testers page.

  • When a patch changes behavior or fixes a noteworthy bug, you should add an entry to the Misc/NEWS file about the change. The file is divided into sections for the core and built-ins, extension modules, the standard library, and accompanying tools, and a change should be described in the appropriate section. You don't need to update the "What's New in Python" document in Doc/whatsnew.

  • Simple or trivial fixes can be just checked in. This is especially true if it's for code or documentation that you own, but you can make a change to another person's module; code ownership is not particularly strict on the Python project. Just be very sure that your fix is correct and doesn't introduce any incompatibilities.

  • When in doubt, don't commit changes. If you're not sure a patch is bug-free, or are in doubt about the approach it takes, don't check in the patch and trust that it'll all get sorted out eventually. Instead, create a patch in the patch tracker (see below) and discuss the patch with the other developers until everyone agrees it's correct.

  • The previous rule applies even more strongly to large patches that touch many files or make far-reaching changes. The Python source tree is managed for stability, meaning that if you make a checkout at a random point in time the tree will almost always compile and be quite stable. Large sets of changes, such as the 2.2 type/class rewrite, are usually tested on a branch first and merged into the main stream of development once they're believed to be complete.

  • Before new releases, code freezes will be announced on python-dev. Obey them and don't make checkins without getting approval on the python-dev list first.

Bug Tracking

To report a bug in Python, use the bug tracker. Don't report bugs by posting them to a mailing list or by sending them to a particular developer as a private e-mail; most likely the bug will end up buried under subsequent postings and e-mails and subsequently forgotten. Once a problem is recorded in the bug tracker, though, it's unlikely to be lost. It may sit unchanged for a while until someone gets around to looking at it, but before releases someone will go over the outstanding bugs and fix or close them. PEP 3, "Guidelines for Handling Bug Reports" explains the procedures for handling bugs once they've been reported.

Patch Tracking

Just like bugs, and for much the same reasons, patches should be submitted to the patch manager, and not through e-mail. Often a patch will need some modification before final acceptance, so be prepared to go through a few iterations before the patch is ready to be checked in.

Some conventions that should be followed when preparing a patch are:

  • Context diffs are preferred, so generate the patch using diff -c.
  • Patches to C code should follow Python's standard style, described in PEP 7, "Style Guide for C Code". If you're using Emacs to edit your C code, cc-mode supports Python's standard style; run the c-set-style command and select the 'python' style.
  • For patches to Jython, the standard formatting and indentation style for Java code should be followed.
  • Code written in Python should follow the style in Guido's style guide, described in PEP 8, "Style Guide for Python Code".

URL Redirectors

SourceForge bug reports have long and ugly URLs:

This would be the link for bug #450000. A redirector has been set up on, so a shorter URL for both bugs and patches is:<bug or patch ID>