From: Mike Bayer Date: Sat, 2 Feb 2013 23:54:54 +0000 (-0500) Subject: whack more long lines in very old docstrings X-Git-Tag: rel_0_8_0~24^2~15 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=d7e4a8529000ce2527861e13ed3f6e8660f35b8f;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git whack more long lines in very old docstrings --- diff --git a/examples/dynamic_dict/__init__.py b/examples/dynamic_dict/__init__.py index 3df907cc54..7f7b0691d3 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 ee1e9e193a..6462dd5629 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 36d50266e2..b6cb240887 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 28a064badd..629808abe9 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 a3b85460cd..09519a679b 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 3982f67993..4098cd53a4 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 b730f71734..1a97b9aef3 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 e8f10e59d3..cec5ad48a3 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 `_. +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 +`_. The example illustrates: diff --git a/examples/versioning/__init__.py b/examples/versioning/__init__.py index 72b5afe966..4621fae3b3 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 b4ce291f27..6073da91c9 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::