Do not start non-heading content on the first character of the line (after
the header).
This commit is contained in:
parent
e6b5c62573
commit
6dada5abfb
59
pep-0200.txt
59
pep-0200.txt
|
@ -17,15 +17,15 @@ Introduction
|
|||
|
||||
Tentative Release Schedule
|
||||
|
||||
Aug. 14: All 2.0 PEPs finished / feature freeze
|
||||
Aug. 28: 2.0 beta 1
|
||||
Sep. 29: 2.0 final
|
||||
Aug. 14: All 2.0 PEPs finished / feature freeze
|
||||
Aug. 28: 2.0 beta 1
|
||||
Sep. 29: 2.0 final
|
||||
|
||||
Guidelines for submitting patches and making changes
|
||||
|
||||
Use good sense when committing changes. You should know what we mean
|
||||
by good sense or we wouldn't have given you commit privileges <0.5
|
||||
wink>. Some specific examples of good sense include:
|
||||
Use good sense when committing changes. You should know what we
|
||||
mean by good sense or we wouldn't have given you commit privileges
|
||||
<0.5 wink>. Some specific examples of good sense include:
|
||||
|
||||
- Do whatever the dictator tells you.
|
||||
|
||||
|
@ -43,35 +43,36 @@ wink>. Some specific examples of good sense include:
|
|||
- You can use the SF Patch Manager to submit a patch and assign it
|
||||
to someone for review.
|
||||
|
||||
Any significant new feature must be described in a PEP and approved
|
||||
before it is checked in.
|
||||
Any significant new feature must be described in a PEP and
|
||||
approved before it is checked in.
|
||||
|
||||
Any significant code addition, such as a new module or large patch,
|
||||
must include test cases for the regression test and documentation. A
|
||||
patch should not be checked in until the tests and documentation are
|
||||
ready.
|
||||
Any significant code addition, such as a new module or large
|
||||
patch, must include test cases for the regression test and
|
||||
documentation. A patch should not be checked in until the tests
|
||||
and documentation are ready.
|
||||
|
||||
If you fix a bug, you should write a test case that would have caught
|
||||
the bug.
|
||||
If you fix a bug, you should write a test case that would have
|
||||
caught the bug.
|
||||
|
||||
If you commit a patch from the SF Patch Manager or fix a bug from the
|
||||
Jitterbug database, be sure to reference the patch/bug number in the
|
||||
CVS log message. Also be sure to change the status in the patch
|
||||
manager or bug database (if you have access to the bug database).
|
||||
If you commit a patch from the SF Patch Manager or fix a bug from
|
||||
the Jitterbug database, be sure to reference the patch/bug number
|
||||
in the CVS log message. Also be sure to change the status in the
|
||||
patch manager or bug database (if you have access to the bug
|
||||
database).
|
||||
|
||||
It is not acceptable for any checked in code to cause the regression
|
||||
test to fail. If a checkin causes a failure, it must be fixed within
|
||||
24 hours or it will be backed out.
|
||||
It is not acceptable for any checked in code to cause the
|
||||
regression test to fail. If a checkin causes a failure, it must
|
||||
be fixed within 24 hours or it will be backed out.
|
||||
|
||||
All contributed C code must be ANSI C. If possible check it with two
|
||||
different compilers, e.g. gcc and MSVC.
|
||||
All contributed C code must be ANSI C. If possible check it with
|
||||
two different compilers, e.g. gcc and MSVC.
|
||||
|
||||
All contributed Python code must follow Guido's Python style guide.
|
||||
http://www.python.org/doc/essays/styleguide.html
|
||||
All contributed Python code must follow Guido's Python style
|
||||
guide. http://www.python.org/doc/essays/styleguide.html
|
||||
|
||||
It is understood that any code contributed will be released under an
|
||||
Open Source license. Do not contribute code if it can't be released
|
||||
this way.
|
||||
It is understood that any code contributed will be released under
|
||||
an Open Source license. Do not contribute code if it can't be
|
||||
released this way.
|
||||
|
||||
Accepted and completed
|
||||
|
||||
|
@ -115,7 +116,7 @@ Open: proposed but not accepted or declined
|
|||
* Eliminated SET_LINENO opcode - Vladimir Marangozov
|
||||
Small optimization achieved by using the code object's lnotab
|
||||
instead of the SET_LINENO instruction. Uses code rewriting
|
||||
technique (that Guido's growns on) to support debugger, which
|
||||
technique (that Guido's frowns on) to support debugger, which
|
||||
uses SET_LINENO.
|
||||
|
||||
http://starship.python.net/~vlad/lineno/
|
||||
|
|
|
@ -263,8 +263,7 @@ Open issues
|
|||
|
||||
References:
|
||||
|
||||
[1]
|
||||
http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470
|
||||
[1] http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470
|
||||
|
||||
|
||||
Local Variables:
|
||||
|
|
Loading…
Reference in New Issue