iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Do not start non-heading content on the first character of the line (after 

the header).
This commit is contained in:
Fred Drake 2000-07-26 04:12:42 +00:00
parent e6b5c62573
commit 6dada5abfb
2 changed files with 31 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
pep-0200.txt
View File

@ -17,15 +17,15 @@ Introduction
Tentative Release Schedule Tentative Release Schedule
Aug. 14: All 2.0 PEPs finished / feature freeze Aug. 14: All 2.0 PEPs finished / feature freeze
Aug. 28: 2.0 beta 1 Aug. 28: 2.0 beta 1
Sep. 29: 2.0 final Sep. 29: 2.0 final
Guidelines for submitting patches and making changes Guidelines for submitting patches and making changes
Use good sense when committing changes. You should know what we mean Use good sense when committing changes. You should know what we
by good sense or we wouldn't have given you commit privileges <0.5 mean by good sense or we wouldn't have given you commit privileges
wink>. Some specific examples of good sense include: <0.5 wink>. Some specific examples of good sense include:
- Do whatever the dictator tells you. - 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 - You can use the SF Patch Manager to submit a patch and assign it
to someone for review. to someone for review.
Any significant new feature must be described in a PEP and approved Any significant new feature must be described in a PEP and
before it is checked in. approved before it is checked in.
Any significant code addition, such as a new module or large patch, Any significant code addition, such as a new module or large
must include test cases for the regression test and documentation. A patch, must include test cases for the regression test and
patch should not be checked in until the tests and documentation are documentation. A patch should not be checked in until the tests
ready. and documentation are ready.
If you fix a bug, you should write a test case that would have caught If you fix a bug, you should write a test case that would have
the bug. caught the bug.
If you commit a patch from the SF Patch Manager or fix a bug from the If you commit a patch from the SF Patch Manager or fix a bug from
Jitterbug database, be sure to reference the patch/bug number in the the Jitterbug database, be sure to reference the patch/bug number
CVS log message. Also be sure to change the status in the patch in the CVS log message. Also be sure to change the status in the
manager or bug database (if you have access to the bug database). 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 It is not acceptable for any checked in code to cause the
test to fail. If a checkin causes a failure, it must be fixed within regression test to fail. If a checkin causes a failure, it must
24 hours or it will be backed out. 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 All contributed C code must be ANSI C. If possible check it with
different compilers, e.g. gcc and MSVC. two different compilers, e.g. gcc and MSVC.
All contributed Python code must follow Guido's Python style guide. All contributed Python code must follow Guido's Python style
http://www.python.org/doc/essays/styleguide.html guide. http://www.python.org/doc/essays/styleguide.html
It is understood that any code contributed will be released under an It is understood that any code contributed will be released under
Open Source license. Do not contribute code if it can't be released an Open Source license. Do not contribute code if it can't be
this way. released this way.
Accepted and completed Accepted and completed
@ -115,7 +116,7 @@ Open: proposed but not accepted or declined
* Eliminated SET_LINENO opcode - Vladimir Marangozov * Eliminated SET_LINENO opcode - Vladimir Marangozov
Small optimization achieved by using the code object's lnotab Small optimization achieved by using the code object's lnotab
instead of the SET_LINENO instruction. Uses code rewriting 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. uses SET_LINENO.
http://starship.python.net/~vlad/lineno/ http://starship.python.net/~vlad/lineno/

3
pep-0204.txt
View File

@ -263,8 +263,7 @@ Open issues
References: References:
[1] [1] http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470
http://sourceforge.net/patch/?func=detailpatch&patch_id=100902&group_id=5470
Local Variables: Local Variables: