Remove trailing whitespace.

1 files changed, 28 insertions, 28 deletions

diff --git a/src/tests/documentation.py b/src/tests/documentation.py
index 2eb6aaa..e752c3f 100644
--- a/src/tests/documentation.py
+++ b/src/tests/documentation.py
@@ -307,11 +307,11 @@ $FUNCTION_ANNOTATIONS
 ``decorator.decorator``
 ---------------------------------------------
 
-It can become tedious to write a caller function (like the above  
+It can become tedious to write a caller function (like the above
 ``_trace`` example) and then a trivial wrapper
-(``def trace(f): return decorate(f, _trace)``) every time. 
-Not to worry!  The ``decorator`` module provides an easy shortcut 
-to convert the caller function into a signature-preserving decorator. 
+(``def trace(f): return decorate(f, _trace)``) every time.
+Not to worry!  The ``decorator`` module provides an easy shortcut
+to convert the caller function into a signature-preserving decorator.
 
 It is the ``decorator`` function:
 
@@ -445,7 +445,7 @@ factory. For instance, if you write this...
 
 
 ...then ``before_after`` is a factory function that returns
-``GeneratorContextManager`` objects, which provide the 
+``GeneratorContextManager`` objects, which provide the
 use of the ``with`` statement:
 
 .. code-block:: python
@@ -474,7 +474,7 @@ a ``__call__`` method, so that they can be used as decorators, like so:
  AFTER
 
 The ``ba`` decorator basically inserts a ``with ba:`` block
-inside the function. 
+inside the function.
 
 However, there are two issues:
 
@@ -640,16 +640,16 @@ Sometimes on the net you find some cool decorator that you would
 like to include in your code. However, more often than not, the cool
 decorator is not signature-preserving. What you need is an easy way to
 upgrade third party decorators to signature-preserving decorators...
-*without* having to rewrite them in terms of ``decorator``. 
+*without* having to rewrite them in terms of ``decorator``.
 
 You can use a ``FunctionMaker`` to implement that functionality as follows:
 
 $$decorator_apply
 
-``decorator_apply`` sets the generated function's ``__wrapped__`` attribute 
-to the original function, so you can get the right source code. 
-If you are using a Python later than 3.2, you should also set the 
-``__qualname__`` attribute to preserve the qualified name of the original 
+``decorator_apply`` sets the generated function's ``__wrapped__`` attribute
+to the original function, so you can get the right source code.
+If you are using a Python later than 3.2, you should also set the
+``__qualname__`` attribute to preserve the qualified name of the original
 function.
 
 Notice that I am not providing this functionality in the ``decorator``
@@ -658,8 +658,8 @@ of adding another level of indirection. However, practicality
 beats purity, so you can add ``decorator_apply`` to your toolbox and
 use it if you need to.
 
-To give a good example for ``decorator_apply``, I will show a pretty slick 
-decorator that converts a tail-recursive function into an iterative function. 
+To give a good example for ``decorator_apply``, I will show a pretty slick
+decorator that converts a tail-recursive function into an iterative function.
 I have shamelessly stolen the core concept from Kay Schluehr's recipe
 in the Python Cookbook,
 http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496691.
@@ -681,10 +681,10 @@ $$factorial
  24
 
 This decorator is pretty impressive, and should give you some food for
-thought! ;) 
+thought! ;)
 
-Notice that there is no recursion limit now; you can easily compute 
-``factorial(1001)`` (or larger) without filling the stack frame. 
+Notice that there is no recursion limit now; you can easily compute
+``factorial(1001)`` (or larger) without filling the stack frame.
 
 Notice also that the decorator will *not* work on functions which
 are not tail recursive, such as the following:
@@ -1002,13 +1002,13 @@ plain function is five times slower::
  1000000 loops, best of 3: 1.39 usec per loop
  1000000 loops, best of 3: 0.278 usec per loop
 
-Of course, a real life function probably does something more useful 
-than ``f`` here, so the real life performance penalty *could* be negligible.  
-As always, the only way to know if there is a penalty in your specific use case 
+Of course, a real life function probably does something more useful
+than ``f`` here, so the real life performance penalty *could* be negligible.
+As always, the only way to know if there is a penalty in your specific use case
 is to measure it.
 
 More importantly, you should be aware that decorators will make your
-tracebacks longer and more difficult to understand. 
+tracebacks longer and more difficult to understand.
 
 Consider this example:
 
@@ -1018,7 +1018,7 @@ Consider this example:
  ... def f():
  ...     1/0
 
-Calling ``f()`` gives you a ``ZeroDivisionError``. 
+Calling ``f()`` gives you a ``ZeroDivisionError``.
 But since the function is decorated, the traceback is longer:
 
 .. code-block:: python
@@ -1064,14 +1064,14 @@ signature.
 
 In the present implementation, decorators generated by ``decorator``
 can only be used on user-defined Python functions or methods.
-They cannot be used on generic callable objects or built-in functions, 
-due to limitations of the standard library's ``inspect`` module, especially 
+They cannot be used on generic callable objects or built-in functions,
+due to limitations of the standard library's ``inspect`` module, especially
 for Python 2. (In Python 3.5, many such limitations have been removed.)
 
 There is a strange quirk when decorating functions with keyword
 arguments, if one of the arguments has the same name used in the
 caller function for the first argument. The quirk was reported by
-David Goldstein. 
+David Goldstein.
 
 Here is an example where it is manifest:
 
@@ -1111,7 +1111,7 @@ This avoids the need to name the first argument, so the problem
 simply disappears. This is a technique that you should keep in mind
 when writing decorators for functions with keyword arguments.
 
-On a similar note, there is a restriction on argument names. For instance, 
+On a similar note, there is a restriction on argument names. For instance,
 if you name an argument ``_call_`` or ``_func_``, you will get a ``NameError``:
 
 .. code-block:: python
@@ -1225,11 +1225,11 @@ You can check that the ``__annotations__`` dictionary is preserved:
   >>> f.__annotations__ is f.__wrapped__.__annotations__
   True
 
-Here ``f.__wrapped__`` is the original undecorated function. 
-This attribute exists for consistency with the behavior of 
+Here ``f.__wrapped__`` is the original undecorated function.
+This attribute exists for consistency with the behavior of
 ``functools.update_wrapper``.
 
-Another attribute copied from the original function is ``__qualname__``, 
+Another attribute copied from the original function is ``__qualname__``,
 the qualified name. This attribute was introduced in Python 3.3.
 """