Merge branch 'version-3.1' into oauth_as_package

Conflicts:
	requirements-test.txt
	rest_framework/compat.py
	tests/settings.py
	tox.ini

1 files changed, 4 insertions, 4 deletions

diff --git a/docs/topics/2.2-announcement.md b/docs/topics/2.2-announcement.md
index a997c782..1df52cff 100644
--- a/docs/topics/2.2-announcement.md
+++ b/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`.