Python Patch Submission Guidelines

New: CNRI is no longer involved in Python patches. We no longer request legal disclaimers. Also, We're now using the SourceForge Patch Manager (a single mailing list became unmanageable).

Many people contribute patches to Python. We've set up a new system to deal with these. Here are the main guidelines:

• Submit your patch to the patch manager interface at SourceForge. We strongly recommend that you register with SourceForge before submitting a patch. If you send patches directly to Guido you introduce an extra delay. Ditto for the "patches@python.org" mailing list address; this address should no longer be used for patch submission. The patch manager is for patches only; if you have a problem or suggestion but don't know how to write the code for it, use the Python Bugs List instead. The bugs list is searchable; if you have a problem and you're not sure if it has been reported or fixed already, this is the first place to look. (There used to be a separate TODO list; we now prefer that you use the bugs list for suggestions and requests too.)

  Submit documentation patches the same way. When adding the patch, be sure to set the "Category" field to "documentation". For documentation errors without patches, please use the Python Bugs List instead.

• We like context diffs. We grudgingly accept unified diffs. Straight ("ed-style") diffs are right out! If you don't know how to generate context diffs, you're probably not qualified to produce high-quality patches anyway <0.5 wink>.

• We appreciate it if you send patches relative to the current CVS tree. These are our latest sources. It's almost a year since Python 1.5.2 was released, and many source files have been touched in more or less significant ways; a patch relative to Python 1.5.2 can cause a lot of extra pain to apply right. Even a patch relative to the latest alpha or beta release may be way out of date.

• Please add a succinct message to your SourceForge entry that explains what the patch is about that we can use directly as a checkin message. Ideally, such a message explains the problem and describes the fix in a few lines.

• For patches that add or change functionality: please also update the documentation and the testcases (the Lib/test subdirectory). For new modules, we appreciate a new test module (typically test/test_spam.py). In this case, there's no need to mail the documentation to a different address (in fact, in order to verify that the bundle is complete, it's easier to mail everything together).

• There are a variety of additional style requirements. Please have a look at these before writing new code. Also have a look at the general Python Style Guide.