Clean up extra white space

docs/topics/2.2-announcement.md

@@ -42,7 +42,7 @@ The 2.2 release makes a few changes to the API, in order to make it more consist
 
 The `ManyRelatedField()` style is being deprecated in favor of a new `RelatedField(many=True)` syntax.
 
-For example, if a user is associated with multiple questions, which we want to represent using a primary key relationship, we might use something like the following: 
+For example, if a user is associated with multiple questions, which we want to represent using a primary key relationship, we might use something like the following:
 
     class UserSerializer(serializers.HyperlinkedModelSerializer):
         questions = serializers.PrimaryKeyRelatedField(many=True)
@@ -58,10 +58,10 @@ The change also applies to serializers.  If you have a nested serializer, you sh
         class Meta:
             model = Track
             fields = ('name', 'duration')
-    
+
     class AlbumSerializer(serializer.ModelSerializer):
         tracks = TrackSerializer(many=True)
-        
+
         class Meta:
             model = Album
             fields = ('album_name', 'artist', 'tracks')
@@ -87,7 +87,7 @@ For example, is a user account has an optional foreign key to a company, that yo
 
 This is in line both with the rest of the serializer fields API, and with Django's `Form` and `ModelForm` API.
 
-Using `required` throughout the serializers API means you won't need to consider if a particular field should take `blank` or `null` arguments instead of `required`, and also means there will be more consistent behavior for how fields are treated when they are not present in the incoming data. 
+Using `required` throughout the serializers API means you won't need to consider if a particular field should take `blank` or `null` arguments instead of `required`, and also means there will be more consistent behavior for how fields are treated when they are not present in the incoming data.
 
 The `null=True` argument will continue to function, and will imply `required=False`, but will raise a `PendingDeprecationWarning`.
 

docs/topics/2.3-announcement.md

@@ -27,7 +27,7 @@ As an example of just how simple REST framework APIs can now be, here's an API w
     class GroupViewSet(viewsets.ModelViewSet):
         model = Group
 
-    
+
     # Routers provide an easy way of automatically determining the URL conf
     router = routers.DefaultRouter()
     router.register(r'users', UserViewSet)
@@ -197,13 +197,13 @@ Usage of the old-style attributes continues to be supported, but will raise a `P
 
 For most cases APIs using model fields will behave as previously, however if you are using a custom renderer, not provided by REST framework, then you may now need to add support for rendering `Decimal` instances to your renderer implementation.
 
-## ModelSerializers and reverse relationships 
+## ModelSerializers and reverse relationships
 
 The support for adding reverse relationships to the `fields` option on a `ModelSerializer` class means that the `get_related_field` and `get_nested_field` method signatures have now changed.
 
 In the unlikely event that you're providing a custom serializer class, and implementing these methods you should note the new call signature for both methods is now `(self, model_field, related_model, to_many)`.  For reverse relationships `model_field` will be `None`.
 
-The old-style signature will continue to function but will raise a `PendingDeprecationWarning`. 
+The old-style signature will continue to function but will raise a `PendingDeprecationWarning`.
 
 ## View names and descriptions
 
@@ -211,7 +211,7 @@ The mechanics of how the names and descriptions used in the browseable API are g
 
 If you've been customizing this behavior, for example perhaps to use `rst` markup for the browseable API, then you'll need to take a look at the implementation to see what updates you need to make.
 
-Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated. 
+Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated.
 
 ---
 

docs/topics/documenting-your-api.md

@@ -54,7 +54,7 @@ The title that is used in the browsable API is generated from the view class nam
 
 For example, the view `UserListView`, will be named `User List` when presented in the browsable API.
 
-When working with viewsets, an appropriate suffix is appended to each generated view.  For example, the view set `UserViewSet` will generate views named `User List` and `User Instance`. 
+When working with viewsets, an appropriate suffix is appended to each generated view.  For example, the view set `UserViewSet` will generate views named `User List` and `User Instance`.
 
 #### Setting the description
 
@@ -65,9 +65,9 @@ If the python `markdown` library is installed, then [markdown syntax][markdown]
     class AccountListView(views.APIView):
         """
         Returns a list of all **active** accounts in the system.
-        
+
         For more details on how accounts are activated please [see here][ref].
-        
+
         [ref]: http://example.com/activating-accounts
         """
 
@@ -84,7 +84,7 @@ You can modify the response behavior to `OPTIONS` requests by overriding the `me
     def metadata(self, request):
         """
         Don't include the view description in OPTIONS responses.
-        """ 
+        """
         data = super(ExampleView, self).metadata(request)
         data.pop('description')
         return data

docs/topics/kickstarter-announcement.md

@@ -160,4 +160,4 @@ The following individuals made a significant financial contribution to the devel
 
 ### Supporters
 
-There were also almost 300 further individuals choosing to help fund the project at other levels or choosing to give anonymously. Again, thank you, thank you, thank you!
+There were also almost 300 further individuals choosing to help fund the project at other levels or choosing to give anonymously. Again, thank you, thank you, thank you!

docs/topics/release-notes.md

@@ -63,7 +63,7 @@ You can determine your currently installed version using `pip freeze`:
 * Bugfix: Fix migration in `authtoken` application.
 * Bugfix: Allow selection of integer keys in nested choices.
 * Bugfix: Return `None` instead of `'None'` in `CharField` with `allow_none=True`.
-* Bugfix: Ensure custom model fields map to equivelent serializer fields more reliably. 
+* Bugfix: Ensure custom model fields map to equivelent serializer fields more reliably.
 * Bugfix: `DjangoFilterBackend` no longer quietly changes queryset ordering.
 
 ### 2.4.2

docs/topics/rest-framework-2-announcement.md

@@ -8,7 +8,7 @@ What it is, and why you should care.
 
 ---
 
-**Announcement:** REST framework 2 released - Tue 30th Oct 2012 
+**Announcement:** REST framework 2 released - Tue 30th Oct 2012
 
 ---
 
@@ -37,7 +37,7 @@ REST framework 2 includes a totally re-worked serialization engine, that was ini
 * A declarative serialization API, that mirrors Django's `Forms`/`ModelForms` API.
 * Structural concerns are decoupled from encoding concerns.
 * Able to support rendering and parsing to many formats, including both machine-readable representations and HTML forms.
-* Validation that can be mapped to obvious and comprehensive error responses. 
+* Validation that can be mapped to obvious and comprehensive error responses.
 * Serializers that support both nested, flat, and partially-nested representations.
 * Relationships that can be expressed as primary keys, hyperlinks, slug fields, and other custom representations.
 

docs/topics/writable-nested-serializers.md

@@ -8,7 +8,7 @@ Although flat data structures serve to properly delineate between the individual
 
 Nested data structures are easy enough to work with if they're read-only - simply nest your serializer classes and you're good to go.  However, there are a few more subtleties to using writable nested serializers, due to the dependencies between the various model instances, and the need to save or delete multiple instances in a single action.
 
-## One-to-many data structures 
+## One-to-many data structures
 
 *Example of a **read-only** nested serializer.  Nothing complex to worry about here.*
 
@@ -16,10 +16,10 @@ Nested data structures are easy enough to work with if they're read-only - simpl
 	    class Meta:
 	        model = ToDoItem
 	        fields = ('text', 'is_completed')
-	
+
 	class ToDoListSerializer(serializers.ModelSerializer):
 	    items = ToDoItemSerializer(many=True, read_only=True)
-	
+
 	    class Meta:
 	        model = ToDoList
 	        fields = ('title', 'items')
@@ -31,7 +31,7 @@ Some example output from our serializer.
         'items': {
             {'text': 'Compile playlist', 'is_completed': True},
             {'text': 'Send invites', 'is_completed': False},
-            {'text': 'Clean house', 'is_completed': False}            
+            {'text': 'Clean house', 'is_completed': False}
         }
     }
 
@@ -44,4 +44,4 @@ Let's take a look at updating our nested one-to-many data structure.
 ### Making PATCH requests
 
 
-[cite]: http://jsonapi.org/format/#url-based-json-api
+[cite]: http://jsonapi.org/format/#url-based-json-api

docs/tutorial/1-serialization.md

@@ -134,7 +134,7 @@ A serializer class is very similar to a Django `Form` class, and includes simila
 
 The field flags can also control how the serializer should be displayed in certain circumstances, such as when rendering to HTML. The `style={'type': 'textarea'}` flag above is equivelent to using `widget=widgets.Textarea` on a Django `Form` class. This is particularly useful for controlling how the browsable API should be displayed, as we'll see later in the tutorial.
 
-We can actually also save ourselves some time by using the `ModelSerializer` class, as we'll see later, but for now we'll keep our serializer definition explicit.  
+We can actually also save ourselves some time by using the `ModelSerializer` class, as we'll see later, but for now we'll keep our serializer definition explicit.
 
 ## Working with Serializers