Python Patch Style Guidelines

Here are some style guidelines for the production of high quality patches to Python. See the patch submission guidelines for additional requirements (such as legal boilerplate, the use of context diffs, and where to mail patches).

  • Don't annotate your changes with comments like "# My patch here" or "# Patched because of ..."; if you have to explain the patch, do so in the text leading up to the message. (On the other hand, if your patch introduces new code or deals with a tricky situation, comments are welcome, of course.)
  • Please match the existing coding style whenever you can. Use the existing indentation style in the file you are editing. (There are two styles: some files use tabs exclusively for indentation, others use 4-space indents. The latter is preferred for new files. A tab character should always be equivalent to 8 spaces, not 4 as is the default in most editors on Mac and Windows.) Make sure all lines fit in 78 columns. When submitting C code, don't use C++ style (//) comments. Write function and method calls like this: foo(arg1, arg2); not like this foo( arg1, arg2 ) nor like this: foo (arg1, arg2). The following statements are not function calls and do not require parentheses: return, del, exec, raise, print. See PEP 8: Python Style Guide for more notes on the preferred coding style.
  • When you have to patch the C source to make it work on a particular platform, please make sure to use the appropriate #ifdef...#endif bracket to avoid enabling the code on other platforms (unless the patch is portable). Read your C compiler or C preprocessor documentation to select the right predefined symbol to test.