[Python-checkins] peps: Wrap at fewer columns.

[antoine.pitrou]

http://hg.python.org/peps/rev/c569e6d4e92c
changeset:   4896:c569e6d4e92c
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Sat May 18 11:00:19 2013 +0200
summary:
  Wrap at fewer columns.

files:
  pep-0442.txt |  36 +++++++++++++++++++-----------------
  1 files changed, 19 insertions(+), 17 deletions(-)


diff --git a/pep-0442.txt b/pep-0442.txt
--- a/pep-0442.txt
+++ b/pep-0442.txt
@@ -54,9 +54,9 @@
 Cyclic trash (CT)
     A reference cycle, or former reference cycle, in which no object
     is referenced from outside the cycle *and* whose objects have
-    started being cleared by the GC.  Objects in cyclic trash are potential
-    zombies; if they are accessed by Python code, the symptoms can vary
-    from weird AttributeErrors to crashes.
+    started being cleared by the GC.  Objects in cyclic trash are
+    potential zombies; if they are accessed by Python code, the symptoms
+    can vary from weird AttributeErrors to crashes.
 
 Zombie / broken object
     An object part of cyclic trash.  The term stresses that the object
@@ -67,13 +67,13 @@
 Finalizer
     A function or method called when an object is intended to be
     disposed of.  The finalizer can access the object and release any
-    resource held by the object (for example mutexes or file descriptors).
-    An example is a ``__del__`` method.
+    resource held by the object (for example mutexes or file
+    descriptors).  An example is a ``__del__`` method.
 
 Resurrection
     The process by which a finalizer creates a new reference to an
-    object in a CI.  This can happen as a quirky but supported side-effect
-    of ``__del__`` methods.
+    object in a CI.  This can happen as a quirky but supported
+    side-effect of ``__del__`` methods.
 
 
 Impact
@@ -123,23 +123,24 @@
 ---------------------------
 
 Cyclic isolates are first detected by the garbage collector, and then
-disposed of.  The detection phase doesn't change and won't be described here.
-Disposal of a CI traditionally works in the following order:
+disposed of.  The detection phase doesn't change and won't be described
+here.  Disposal of a CI traditionally works in the following order:
 
-1. Weakrefs to CI objects are cleared, and their callbacks called. At this
-   point, the objects are still safe to use.
+1. Weakrefs to CI objects are cleared, and their callbacks called. At
+   this point, the objects are still safe to use.
 
 2. The CI becomes a CT as the GC systematically breaks all
    known references inside it (using the ``tp_clear`` function).
 
 3. Nothing.  All CT objects should have been disposed of in step 2
-   (as a side-effect of clearing references); this collection is finished.
+   (as a side-effect of clearing references); this collection is
+   finished.
 
 This PEP proposes to turn CI disposal into the following sequence (new
 steps are in bold):
 
-1. Weakrefs to CI objects are cleared, and their callbacks called. At this
-   point, the objects are still safe to use.
+1. Weakrefs to CI objects are cleared, and their callbacks called. At
+   this point, the objects are still safe to use.
 
 2. **The finalizers of all CI objects are called.**
 
@@ -152,7 +153,8 @@
    known references inside it (using the ``tp_clear`` function).
 
 5. Nothing.  All CT objects should have been disposed of in step 4
-   (as a side-effect of clearing references); this collection is finished.
+   (as a side-effect of clearing references); this collection is
+   finished.
 
 
 C-level changes
@@ -172,8 +174,8 @@
 
 On the internal side, a bit is reserved in the GC header for GC-managed
 objects to signal that they were finalized.  This helps avoid finalizing
-an object twice (and, especially, finalizing a CT object after it was broken
-by the GC).
+an object twice (and, especially, finalizing a CT object after it was
+broken by the GC).
 
 
 Discussion

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