Python Patch Submission Guidelines

We're using the SourceForge Patch Manager. Here are the main guidelines:

• Submit your patch to the patch manager interface at SourceForge. You will need to register with SourceForge, and you will need to login before submitting a patch, or else the 'Submit New' link will not appear. 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 bug manager instead.
• 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 bugs manager instead.
• We like unified diffs. We grudgingly accept contextual 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>.
• Please use forward diffs. That is, use "diff -u oldfile newfile", and not the other way around.
• If you send diffs for multiple files, concatenate all the diffs in a single text file. Please don't produce a zip file with multiple patches.
• We appreciate it if you send patches relative to the current svn tree. These are our latest sources. 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 PEP 8: Python Style Guide.