whack more long lines in very old docstrings

10 files changed, 54 insertions, 29 deletions

diff --git a/examples/dynamic_dict/__init__.py b/examples/dynamic_dict/__init__.py
index 3df907cc5..7f7b0691d 100644
--- a/examples/dynamic_dict/__init__.py
+++ b/examples/dynamic_dict/__init__.py
@@ -1,5 +1,6 @@
-"""Illustrates how to place a dictionary-like facade on top of a "dynamic" relation, so
-that dictionary operations (assuming simple string keys) can operate upon a large
-collection without loading the full collection at once.
+""" Illustrates how to place a dictionary-like facade on top of a
+"dynamic" relation, so that dictionary operations (assuming simple
+string keys) can operate upon a large collection without loading the
+full collection at once.
 
 """
\ No newline at end of file
diff --git a/examples/elementtree/__init__.py b/examples/elementtree/__init__.py
index ee1e9e193..6462dd562 100644
--- a/examples/elementtree/__init__.py
+++ b/examples/elementtree/__init__.py
@@ -9,16 +9,23 @@ xpath-like strings is illustrated as well.
 
 In order of complexity:
 
-* ``pickle.py`` - Quick and dirty, serialize the whole DOM into a BLOB column.  While the example
-  is very brief, it has very limited functionality.
-* ``adjacency_list.py`` - Each DOM node is stored in an individual table row, with attributes
-  represented in a separate table.  The nodes are associated in a hierarchy using an adjacency list
-  structure.  A query function is introduced which can search for nodes along any path with a given
-  structure of attributes, basically a (very narrow) subset of xpath.
-* ``optimized_al.py`` - Uses the same strategy as ``adjacency_list.py``, but associates each
-  DOM row with its owning document row, so that a full document of DOM nodes can be
-  loaded using O(1) queries - the construction of the "hierarchy" is performed after
-  the load in a non-recursive fashion and is much more efficient.
+* ``pickle.py`` - Quick and dirty, serialize the whole DOM into a BLOB
+  column.  While the example   is very brief, it has very limited
+  functionality.
+
+* ``adjacency_list.py`` - Each DOM node is stored in an individual
+  table row, with attributes   represented in a separate table.  The
+  nodes are associated in a hierarchy using an adjacency list
+  structure.  A query function is introduced which can search for nodes
+  along any path with a given   structure of attributes, basically a
+  (very narrow) subset of xpath.
+
+* ``optimized_al.py`` - Uses the same strategy as
+  ``adjacency_list.py``, but associates each   DOM row with its owning
+  document row, so that a full document of DOM nodes can be   loaded
+  using O(1) queries - the construction of the "hierarchy" is performed
+  after the load in a non-recursive fashion and is much more
+  efficient.
 
 E.g.::
 
diff --git a/examples/generic_associations/__init__.py b/examples/generic_associations/__init__.py
index 36d50266e..b6cb24088 100644
--- a/examples/generic_associations/__init__.py
+++ b/examples/generic_associations/__init__.py
@@ -19,6 +19,7 @@ The configurations include:
 
 The ``discriminator_on_association.py`` script in particular is a modernized
 version of the "polymorphic associations" example present in older versions of
-SQLAlchemy, originally from the blog post at http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/.
+SQLAlchemy, originally from the blog post at
+http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/.
 
 """
\ No newline at end of file
diff --git a/examples/graphs/__init__.py b/examples/graphs/__init__.py
index 28a064bad..629808abe 100644
--- a/examples/graphs/__init__.py
+++ b/examples/graphs/__init__.py
@@ -1,5 +1,7 @@
-"""
-An example of persistence for a directed graph structure.   The graph is stored as a collection of edges, each referencing both a "lower" and an "upper" node in a table of nodes.  Basic persistence and querying for lower- and upper- neighbors are illustrated::
+"""An example of persistence for a directed graph structure.   The
+graph is stored as a collection of edges, each referencing both a
+"lower" and an "upper" node in a table of nodes.  Basic persistence
+and querying for lower- and upper- neighbors are illustrated::
 
     n2 = Node(2)
     n5 = Node(5)
diff --git a/examples/inheritance/__init__.py b/examples/inheritance/__init__.py
index a3b85460c..09519a679 100644
--- a/examples/inheritance/__init__.py
+++ b/examples/inheritance/__init__.py
@@ -1,4 +1,4 @@
-"""
-Working examples of single-table, joined-table, and concrete-table inheritance as described in :ref:`datamapping_inheritance`.
+"""Working examples of single-table, joined-table, and concrete-table
+inheritance as described in :ref:`datamapping_inheritance`.
 
 """
\ No newline at end of file
diff --git a/examples/large_collection/__init__.py b/examples/large_collection/__init__.py
index 3982f6799..4098cd53a 100644
--- a/examples/large_collection/__init__.py
+++ b/examples/large_collection/__init__.py
@@ -1,8 +1,12 @@
 """Large collection example.
 
-Illustrates the options to use with :func:`~sqlalchemy.orm.relationship()` when the list of related objects is very large, including:
+Illustrates the options to use with
+:func:`~sqlalchemy.orm.relationship()` when the list of related
+objects is very large, including:
 
 * "dynamic" relationships which query slices of data as accessed
-* how to use ON DELETE CASCADE in conjunction with ``passive_deletes=True`` to greatly improve the performance of related collection deletion.
+* how to use ON DELETE CASCADE in conjunction with
+  ``passive_deletes=True`` to greatly improve the performance of
+  related collection deletion.
 
 """
diff --git a/examples/nested_sets/__init__.py b/examples/nested_sets/__init__.py
index b730f7173..1a97b9aef 100644
--- a/examples/nested_sets/__init__.py
+++ b/examples/nested_sets/__init__.py
@@ -1,4 +1,4 @@
-"""
-Illustrates a rudimentary way to implement the "nested sets" pattern for hierarchical data using the SQLAlchemy ORM.
+""" Illustrates a rudimentary way to implement the "nested sets"
+pattern for hierarchical data using the SQLAlchemy ORM.
 
 """
\ No newline at end of file
diff --git a/examples/postgis/__init__.py b/examples/postgis/__init__.py
index e8f10e59d..cec5ad48a 100644
--- a/examples/postgis/__init__.py
+++ b/examples/postgis/__init__.py
@@ -1,7 +1,10 @@
 """A naive example illustrating techniques to help
 embed PostGIS functionality.
 
-This example was originally developed in the hopes that it would be extrapolated into a comprehensive PostGIS integration layer.  We are pleased to announce that this has come to fruition as `GeoAlchemy <http://www.geoalchemy.org/>`_.
+This example was originally developed in the hopes that it would be
+extrapolated into a comprehensive PostGIS integration layer.  We are
+pleased to announce that this has come to fruition as `GeoAlchemy
+<http://www.geoalchemy.org/>`_.
 
 The example illustrates:
 
diff --git a/examples/versioning/__init__.py b/examples/versioning/__init__.py
index 72b5afe96..4621fae3b 100644
--- a/examples/versioning/__init__.py
+++ b/examples/versioning/__init__.py
@@ -46,8 +46,9 @@ A fragment of example usage, using declarative::
                 all() \\
                 == [SomeClassHistory(version=1, name='sc1')]
 
-The ``Versioned`` mixin is designed to work with declarative.  To use the extension with
-classical mappers, the ``_history_mapper`` function can be applied::
+The ``Versioned`` mixin is designed to work with declarative.  To use
+the extension with classical mappers, the ``_history_mapper`` function
+can be applied::
 
     from history_meta import _history_mapper
 
diff --git a/examples/vertical/__init__.py b/examples/vertical/__init__.py
index b4ce291f2..6073da91c 100644
--- a/examples/vertical/__init__.py
+++ b/examples/vertical/__init__.py
@@ -1,10 +1,16 @@
 """
 Illustrates "vertical table" mappings.
 
-A "vertical table" refers to a technique where individual attributes of an object are stored as distinct rows in a table.
-The "vertical table" technique is used to persist objects which can have a varied set of attributes, at the expense of simple query control and brevity.   It is commonly found in content/document management systems in order to represent user-created structures flexibly.
-
-Two variants on the approach are given.  In the second, each row references a "datatype" which contains information about the type of information stored in the attribute, such as integer, string, or date.
+A "vertical table" refers to a technique where individual attributes
+of an object are stored as distinct rows in a table. The "vertical
+table" technique is used to persist objects which can have a varied
+set of attributes, at the expense of simple query control and brevity.
+It is commonly found in content/document management systems in order
+to represent user-created structures flexibly.
+
+Two variants on the approach are given.  In the second, each row
+references a "datatype" which contains information about the type of
+information stored in the attribute, such as integer, string, or date.
 
 
 Example::