From 10a30c85ee624af05a27227bc9abdc9f02b9bdea Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Tue, 9 Oct 2012 03:02:36 -0400 Subject: [PATCH] indentation --- CHANGES.txt | 108 ++++++++++++++++++++++++++-------------------------- 1 file changed, 54 insertions(+), 54 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 4154284..6401615 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -58,8 +58,8 @@ Features ranged_int = RangedInt() - Values that are expected to be callables can now alternately be methods of - the schemanode subclass instead of plain attributes:: + Values that are expected to be callables can now alternately be methods of + the schemanode subclass instead of plain attributes:: from colander import SchemaNode @@ -73,17 +73,17 @@ Features ranged_int = RangedInt() - Note that when implementing a method value such as ``validator`` that - expects to receive a ``node`` argument, ``node`` must be provided in the - call signature, even though ``node`` will almost always be the same as - ``self``. This is because Colander simply treats the method as another - kind of callable, be it a method, or a function, or an instance that has a - ``__call__`` method. It doesn't care that it happens to be a method of - ``self``, and it needs to support callables that are not methods, so it - sends ``node`` in regardless. + Note that when implementing a method value such as ``validator`` that + expects to receive a ``node`` argument, ``node`` must be provided in the + call signature, even though ``node`` will almost always be the same as + ``self``. This is because Colander simply treats the method as another + kind of callable, be it a method, or a function, or an instance that has a + ``__call__`` method. It doesn't care that it happens to be a method of + ``self``, and it needs to support callables that are not methods, so it + sends ``node`` in regardless. - You can't currently use *method* definitions as ``colander.deferred`` - callables. For example this will *not* work:: + You can't currently use *method* definitions as ``colander.deferred`` + callables. For example this will *not* work:: from colander import SchemaNode @@ -103,13 +103,13 @@ Features ranged_int = RangedInt() bound_ranged_int = ranged_int.bind(request=request) - This will result in:: + This will result in:: TypeError: avalidator() takes exactly 3 arguments (2 given) - However, if you treat the thing being decorated as a function instead of a - method (remove the ``self`` argument from the argument list), it will - indeed work):: + However, if you treat the thing being decorated as a function instead of a + method (remove the ``self`` argument from the argument list), it will + indeed work):: from colander import SchemaNode @@ -129,11 +129,11 @@ Features ranged_int = RangedInt() bound_ranged_int = ranged_int.bind(request=request) - In previous releases of Colander, the only way to defer the computation of - values was via the ``colander.deferred`` decorator. In this release, - however, you can instead use the ``bindings`` attribute of ``self`` to - obtain access to the bind parameters within values that are plain old - methods:: + In previous releases of Colander, the only way to defer the computation of + values was via the ``colander.deferred`` decorator. In this release, + however, you can instead use the ``bindings`` attribute of ``self`` to + obtain access to the bind parameters within values that are plain old + methods:: from colander import SchemaNode @@ -150,10 +150,10 @@ Features ranged_int = RangedInt() bound_range_int = ranged_int.bind(request=request) - If the things you're trying to defer aren't callables like ``validator``, - but they're instead just plain attributes like ``missing`` or ``default``, - instead of using a ``colander.deferred``, you can use ``after_bind`` to - set attributes of the schemanode that rely on binding variables:: + If the things you're trying to defer aren't callables like ``validator``, + but they're instead just plain attributes like ``missing`` or ``default``, + instead of using a ``colander.deferred``, you can use ``after_bind`` to set + attributes of the schemanode that rely on binding variables:: from colander import SchemaNode @@ -163,8 +163,8 @@ Features def after_bind(self, node, kw): self.default = kw['request'].user.id - You can override the default values of a schemanode subclass in its - constructor:: + You can override the default values of a schemanode subclass in its + constructor:: from colander import SchemaNode @@ -175,12 +175,12 @@ Features ranged_int = RangedInt(validator=colander.Range(0, 20)) - In the above example, the validation will be done on 0-20, not 0-10. + In the above example, the validation will be done on 0-20, not 0-10. - If a schema node name conflicts with a schema value attribute name on the - same class, you can work around it by giving the schema node a bogus name - in the class definition but providing a correct ``name`` argument to the - schema node constructor:: + If a schema node name conflicts with a schema value attribute name on the + same class, you can work around it by giving the schema node a bogus name + in the class definition but providing a correct ``name`` argument to the + schema node constructor:: from colander import SchemaNode, Schema @@ -213,16 +213,16 @@ Features ``title`` attribute will be ``Some Schema`` (schema.title will return ``Some Schema``). - Normal inheritance rules apply to class attributes and methods defined in - a schemanode subclass. If your schemanode subclass inherits from another - schemanode class, your schemanode subclass' methods and class attributes - will override the superclass' methods and class attributes. + Normal inheritance rules apply to class attributes and methods defined in + a schemanode subclass. If your schemanode subclass inherits from another + schemanode class, your schemanode subclass' methods and class attributes + will override the superclass' methods and class attributes. - Ordering of child schema nodes when inheritance is used works like this: - the "deepest" SchemaNode class in the MRO of the inheritance chain is - consulted first for nodes, then the next deepest, then the next, and so - on. So the deepest class' nodes come first in the relative ordering of - schema nodes, then the next deepest, and so on. For example:: + Ordering of child schema nodes when inheritance is used works like this: + the "deepest" SchemaNode class in the MRO of the inheritance chain is + consulted first for nodes, then the next deepest, then the next, and so on. + So the deepest class' nodes come first in the relative ordering of schema + nodes, then the next deepest, and so on. For example:: class One(colander.Schema): a = colander.SchemaNode( @@ -268,17 +268,17 @@ Features three = Three() - The ordering of child nodes computed in the schema node ``three`` will be - ``['a2', 'b3', 'd3', 'c2', 'e2', 'f3']``. The ordering starts ``a1``, - ``b1``, ``d1`` because that's the ordering of nodes in ``One``, and - ``One`` is the deepest SchemaNode in the inheritance hierarchy. Then it - processes the nodes attached to ``Two``, the next deepest, which causes - ``a1`` to be replaced by ``a2``, and ``c2`` and ``e2`` to be appended to - the node list. Then finally it processes the nodes attached to ``Three``, - which causes ``b1`` to be replaced by ``b3``, and ``d1`` to be replaced by - ``d3``, then finally ``f`` is appended. + The ordering of child nodes computed in the schema node ``three`` will be + ``['a2', 'b3', 'd3', 'c2', 'e2', 'f3']``. The ordering starts ``a1``, + ``b1``, ``d1`` because that's the ordering of nodes in ``One``, and + ``One`` is the deepest SchemaNode in the inheritance hierarchy. Then it + processes the nodes attached to ``Two``, the next deepest, which causes + ``a1`` to be replaced by ``a2``, and ``c2`` and ``e2`` to be appended to + the node list. Then finally it processes the nodes attached to ``Three``, + which causes ``b1`` to be replaced by ``b3``, and ``d1`` to be replaced by + ``d3``, then finally ``f`` is appended. - Multiple inheritance works the same way:: + Multiple inheritance works the same way:: class One(colander.Schema): a = colander.SchemaNode( @@ -324,9 +324,9 @@ Features three = Three() - The resulting node ordering of ``three`` is the same as the single - inheritance example: ``['a2', 'b3', 'd3', 'c2', 'e2', 'f3']`` due to the - MRO deepest-first ordering (``One``, then ``Two``, then ``Three``). + The resulting node ordering of ``three`` is the same as the single + inheritance example: ``['a2', 'b3', 'd3', 'c2', 'e2', 'f3']`` due to the + MRO deepest-first ordering (``One``, then ``Two``, then ``Three``). Backwards Incompatibilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~