[Python-checkins] peps: Do not start non-heading content on the first character of the line (after

[georg.brandl]

http://hg.python.org/peps/rev/15df0f2a1b39
changeset:   49:15df0f2a1b39
user:        Fred Drake <fdrake at acm.org>
date:        Wed Jul 26 04:12:42 2000 +0000
summary:
  Do not start non-heading content on the first character of the line (after
the header).

files:
  pep-0200.txt |  59 ++++++++++++++++++++-------------------
  pep-0204.txt |   3 +-
  2 files changed, 31 insertions(+), 31 deletions(-)


diff --git a/pep-0200.txt b/pep-0200.txt
--- a/pep-0200.txt
+++ b/pep-0200.txt
@@ -17,15 +17,15 @@
 
 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 @@
     - 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 @@
     * 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/
diff --git a/pep-0204.txt b/pep-0204.txt
--- a/pep-0204.txt
+++ b/pep-0204.txt
@@ -263,8 +263,7 @@
 
 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:

-- 
Repository URL: http://hg.python.org/peps