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.
|
