internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: encode/django-rest-framework

Issue:
HTTP 204 has a Content-Type header
I've noticed I'm getting WSGI warnings from my DRF app due to:

```
WSGIWarning: Content-Type header found in a 204 response, which not return content.
```

Is this the intended behaviour of DRF, or would you be interested in a patch to change the Content-Type setting for 204 responses?



Discussion:
> would you be interested in a patch to change the Content-Type setting for 204 responses?

That'd be reasonable yeah.  It's possible that it might be difficult though - I'm not sure but Django's response machinery might end up providing a default one if it's not added?


Resolving patch:
diff --git a/rest_framework/response.py b/rest_framework/response.py
--- a/rest_framework/response.py
+++ b/rest_framework/response.py
@@ -61,6 +61,10 @@ def rendered_content(self):
             assert charset, 'renderer returned unicode, and did not specify ' \
             'a charset value.'
             return bytes(ret.encode(charset))
+
+        if not ret:
+            del self['Content-Type']
+
         return ret
 
     @property


Test patch:
diff --git a/rest_framework/tests/test_renderers.py b/rest_framework/tests/test_renderers.py
--- a/rest_framework/tests/test_renderers.py
+++ b/rest_framework/tests/test_renderers.py
@@ -64,11 +64,16 @@ def get(self, request, **kwargs):
 
 
 class MockGETView(APIView):
-
     def get(self, request, **kwargs):
         return Response({'foo': ['bar', 'baz']})
 
 
+class EmptyGETView(APIView):
+    renderer_classes = (JSONRenderer,)
+
+    def get(self, request, **kwargs):
+        return Response(status=status.HTTP_204_NO_CONTENT)
+
 class HTMLView(APIView):
     renderer_classes = (BrowsableAPIRenderer, )
 
@@ -90,6 +95,7 @@ def get(self, request, **kwargs):
     url(r'^jsonp/nojsonrenderer$', MockGETView.as_view(renderer_classes=[JSONPRenderer])),
     url(r'^html$', HTMLView.as_view()),
     url(r'^html1$', HTMLView1.as_view()),
+    url(r'^empty$', EmptyGETView.as_view()),
     url(r'^api', include('rest_framework.urls', namespace='rest_framework'))
 )
 
@@ -219,6 +225,16 @@ def test_specified_renderer_is_used_on_format_query_with_matching_accept(self):
         self.assertEqual(resp.content, RENDERER_B_SERIALIZER(DUMMYCONTENT))
         self.assertEqual(resp.status_code, DUMMYSTATUS)
 
+    def test_204_no_content_responses_have_no_content_type_set(self):
+        """
+        Regression test for #1196
+
+        https://github.com/tomchristie/django-rest-framework/issues/1196
+        """
+        resp = self.client.get('/empty')
+        self.assertEqual(resp.get('Content-Type', None), None)
+        self.assertEqual(resp.status_code, status.HTTP_204_NO_CONTENT)
+
 
 _flat_repr = '{"foo": ["bar", "baz"]}'
 _indented_repr = '{\n  "foo": [\n    "bar",\n    "baz"\n  ]\n}'
Repository: encode/django-rest-framework

Issue:
Stop breaking non-model usage in serializer
45d4622f090f8d81a04b4d3e888017419676bbc0 added a weird workaround for a problem that has nothing to do with the `BaseSerializer` but is tailor made for the Django ORM.

I'm trying to use DRF with elasticutils' search querysets and been wondering why the serializer always returns ALL results, instead of the ones I told the paginator to return. The `all` method returns all objects, no matter what filter or query has been done before.

As to how to fix this, I would propose that this code needs to live in the `ModelSerializer.field_to_native` method not in its parent class. That would help non-Django ORM uses greatly.



Discussion:
Amusingly, I wrote the code that's causing this bug.. and I ran into it myself a few weeks ago. If you try to serialize a queryset that's been returned from a cache, the `all()` call will force the queryset to be cloned, which will cause a database query - making the cached version pointless.

Any suggestions for a better approach would be welcomed!

Not sure if that's the way to go, one test is not passing sadly, I'd be happy to also fix that, but I'm a bit uncertain why it would do that. @tomchristie Any idea?

@jezdez Been thinking about this and reckon the sensible way to resolve this is not to remove `.all()` handling from the serializer class, but just tweak _when_ it gets used.  Simply moving it into ModelSerializer would introduce a really subtle difference between serializers and model serializers.  At the moment the difference is fairly simple to explain:
- ModelSerializers get fields automatically generated.
- ModelSerializers have automatic restore object and save behaviour.

I think we should change the behavior so that `.all()` only gets used if:
- `many=True` has been explicitly set.
- The attribute does not have an `__iter__` but does have an `all()`

Note that this approach would also fix @j4mie's issue, as querysets would simply be iterated over, wheras model managers would (necessarily) have `all()` applied.

@tomchristie That would make sense to me, indeed!


Resolving patch:
diff --git a/rest_framework/serializers.py b/rest_framework/serializers.py
--- a/rest_framework/serializers.py
+++ b/rest_framework/serializers.py
@@ -412,7 +412,13 @@ def field_from_native(self, data, files, field_name, into):
 
         # Set the serializer object if it exists
         obj = get_component(self.parent.object, self.source or field_name) if self.parent.object else None
-        obj = obj.all() if is_simple_callable(getattr(obj, 'all', None)) else obj
+
+        # If we have a model manager or similar object then we need
+        # to iterate through each instance.
+        if (self.many and
+            not hasattr(obj, '__iter__') and
+            is_simple_callable(getattr(obj, 'all', None))):
+            obj = obj.all()
 
         if self.source == '*':
             if value:


Test patch:
Repository: encode/django-rest-framework

Issue:
Possible error in Docstring,
In the `Field` class, the [docstring](https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/fields.py#L167) for the `initialize` method seems to have a mistake.

The comment refers to a `model_field` parameter, but the parameters in the function are called `parent` and `field_name`.



Discussion:
Yep. Looks like it should be `field_name`. @maurodec fancy doing a pull request correcting that?


Resolving patch:
diff --git a/rest_framework/fields.py b/rest_framework/fields.py
--- a/rest_framework/fields.py
+++ b/rest_framework/fields.py
@@ -164,7 +164,7 @@ def initialize(self, parent, field_name):
         Called to set up a field prior to field_to_native or field_from_native.
 
         parent - The parent serializer.
-        model_field - The model field this field corresponds to, if one exists.
+        field_name - The name of the field being initialized.
         """
         self.parent = parent
         self.root = parent.root or parent


Test patch:
Repository: encode/django-rest-framework

Issue:
YAML cripples unicode
While a CharField is containing no unicode (i.e. non-ASCII), I see it in YAML API nicely:

```
full_name: Miro Hroncok
```

However, if it contains non-ASCII chars, I get:

```
full_name: "Miro Hron\u010Dok"
```

While the following would be much nicer (and fairly loadable by PyYAML):

```
full_name: Miro Hrončok
```

I have a fix in mind.



Discussion:

Resolving patch:
diff --git a/rest_framework/renderers.py b/rest_framework/renderers.py
--- a/rest_framework/renderers.py
+++ b/rest_framework/renderers.py
@@ -193,6 +193,7 @@ class YAMLRenderer(BaseRenderer):
     format = 'yaml'
     encoder = encoders.SafeDumper
     charset = 'utf-8'
+    ensure_ascii = True
 
     def render(self, data, accepted_media_type=None, renderer_context=None):
         """
@@ -203,7 +204,15 @@ def render(self, data, accepted_media_type=None, renderer_context=None):
         if data is None:
             return ''
 
-        return yaml.dump(data, stream=None, encoding=self.charset, Dumper=self.encoder)
+        return yaml.dump(data, stream=None, encoding=self.charset, Dumper=self.encoder, allow_unicode=not self.ensure_ascii)
+
+
+class UnicodeYAMLRenderer(YAMLRenderer):
+    """
+    Renderer which serializes to YAML.
+    Does *not* apply character escaping for non-ascii characters.
+    """
+    ensure_ascii = False
 
 
 class TemplateHTMLRenderer(BaseRenderer):


Test patch:
diff --git a/rest_framework/tests/test_renderers.py b/rest_framework/tests/test_renderers.py
--- a/rest_framework/tests/test_renderers.py
+++ b/rest_framework/tests/test_renderers.py
@@ -12,7 +12,7 @@
 from rest_framework.response import Response
 from rest_framework.views import APIView
 from rest_framework.renderers import BaseRenderer, JSONRenderer, YAMLRenderer, \
-    XMLRenderer, JSONPRenderer, BrowsableAPIRenderer, UnicodeJSONRenderer
+    XMLRenderer, JSONPRenderer, BrowsableAPIRenderer, UnicodeJSONRenderer, UnicodeYAMLRenderer
 from rest_framework.parsers import YAMLParser, XMLParser
 from rest_framework.settings import api_settings
 from rest_framework.test import APIRequestFactory
@@ -467,6 +467,17 @@ def assertYAMLContains(self, content, string):
             self.assertTrue(string in content, '%r not in %r' % (string, content))
 
 
+    class UnicodeYAMLRendererTests(TestCase):
+        """
+        Tests specific for the Unicode YAML Renderer
+        """
+        def test_proper_encoding(self):
+            obj = {'countries': ['United Kingdom', 'France', 'España']}
+            renderer = UnicodeYAMLRenderer()
+            content = renderer.render(obj, 'application/yaml')
+            self.assertEqual(content.strip(), 'countries: [United Kingdom, France, España]'.encode('utf-8'))
+
+
 class XMLRendererTestCase(TestCase):
     """
     Tests specific to the XML Renderer
Repository: encode/django-rest-framework

Issue:
`X-Http-Method-Override` and non-uppercase `request.method`
Found a minor problem.

According to the documentation, http://www.django-rest-framework.org/api-guide/requests#method:

```
       request.method returns the uppercased string representation of the request's HTTP method.
```

From https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/request.py#L283:

```
        # Allow X-HTTP-METHOD-OVERRIDE header
        self._method = self.META.get('HTTP_X_HTTP_METHOD_OVERRIDE',
                                     self._method)
```

That means if the X-Http-Method-Override header was set to `"Patch"` instead of `"PATCH"`, the `request.method` will no longer be fully uppercased, causing problems when comparing method names in the views code checking for permissions, e.g. `if request.method == 'PATCH'`. 

So the documentation and the code aren't fully congruent. Changing the line to:

```
        self._method = self.META.get('HTTP_X_HTTP_METHOD_OVERRIDE',
                                     self._method).upper()
```

would fix it, but it would prevent using custom case-sensitive method names. I'm not sure that's a sensible idea anyway but it's a limitation. Alternatively, the documentation could be corrected to:

```
        request.method returns the uppercased string representation of the request's HTTP method, except when the method is overridden using the header 'X-Http-Method-Override'.
```

I encountered this problem since the javascript REST client (restangular) I was using was assigning lower cased method names to the X-Http-Method-Override header. 

Love Django REST framework, keep up the good work!



Discussion:
> custom case-sensitive method names

Don't want to support them. Go wild with the uppercasing. :space_invader: :sparkles: 


Resolving patch:
diff --git a/rest_framework/request.py b/rest_framework/request.py
--- a/rest_framework/request.py
+++ b/rest_framework/request.py
@@ -280,8 +280,8 @@ def _load_method_and_content_type(self):
             self._method = self._request.method
 
             # Allow X-HTTP-METHOD-OVERRIDE header
-            self._method = self.META.get('HTTP_X_HTTP_METHOD_OVERRIDE',
-                                         self._method)
+            if 'HTTP_X_HTTP_METHOD_OVERRIDE' in self.META:
+                self._method = self.META['HTTP_X_HTTP_METHOD_OVERRIDE'].upper()
 
     def _load_stream(self):
         """


Test patch:
Repository: encode/django-rest-framework

Issue:
Modify filters in `get_filter_backends` changes all default filters
If you alter the returned list in an overridden `GenericAPIView.get_filter_backends` than it gets modified for all viewsets that use the default value.

When you modify that value without copying it then you actually modify the `GenericAPIView.filter_backends` list.



Discussion:
Yup - we should probably be returning a copy of `self.filter_backends` rather than returning the class attribute directly.


Resolving patch:
diff --git a/rest_framework/generics.py b/rest_framework/generics.py
--- a/rest_framework/generics.py
+++ b/rest_framework/generics.py
@@ -189,7 +189,13 @@ def get_filter_backends(self):
         """
         Returns the list of filter backends that this view requires.
         """
-        filter_backends = self.filter_backends or []
+        if self.filter_backends is None:
+            filter_backends = []
+        else:
+            # Note that we are returning a *copy* of the class attribute,
+            # so that it is safe for the view to mutate it if needed.
+            filter_backends = list(self.filter_backends)
+
         if not filter_backends and self.filter_backend:
             warnings.warn(
                 'The `filter_backend` attribute and `FILTER_BACKEND` setting '
@@ -199,6 +205,7 @@ def get_filter_backends(self):
                 PendingDeprecationWarning, stacklevel=2
             )
             filter_backends = [self.filter_backend]
+
         return filter_backends
 
 


Test patch:
Repository: encode/django-rest-framework

Issue:
Ensure docstrings are coerced into a string, in order to support translated strings.
Closes #1708



Discussion:

Resolving patch:
diff --git a/rest_framework/utils/formatting.py b/rest_framework/utils/formatting.py
--- a/rest_framework/utils/formatting.py
+++ b/rest_framework/utils/formatting.py
@@ -2,11 +2,12 @@
 Utility functions to return a formatted name and description for a given view.
 """
 from __future__ import unicode_literals
+import re
 
 from django.utils.html import escape
 from django.utils.safestring import mark_safe
-from rest_framework.compat import apply_markdown
-import re
+
+from rest_framework.compat import apply_markdown, force_text
 
 
 def remove_trailing_string(content, trailing):
@@ -28,6 +29,7 @@ def dedent(content):
     as it fails to dedent multiline docstrings that include
     unindented text on the initial line.
     """
+    content = force_text(content)
     whitespace_counts = [len(line) - len(line.lstrip(' '))
                          for line in content.splitlines()[1:] if line.lstrip()]
 


Test patch:
diff --git a/tests/test_description.py b/tests/test_description.py
--- a/tests/test_description.py
+++ b/tests/test_description.py
@@ -98,6 +98,30 @@ class MockView(APIView):
             pass
         self.assertEqual(MockView().get_view_description(), '')
 
+    def test_view_description_can_be_promise(self):
+        """
+        Ensure a view may have a docstring that is actually a lazily evaluated
+        class that can be converted to a string.
+
+        See: https://github.com/tomchristie/django-rest-framework/issues/1708
+        """
+        # use a mock object instead of gettext_lazy to ensure that we can't end
+        # up with a test case string in our l10n catalog
+        class MockLazyStr(object):
+            def __init__(self, string):
+                self.s = string
+
+            def __str__(self):
+                return self.s
+
+            def __unicode__(self):
+                return self.s
+
+        class MockView(APIView):
+            __doc__ = MockLazyStr("a gettext string")
+
+        self.assertEqual(MockView().get_view_description(), 'a gettext string')
+
     def test_markdown(self):
         """
         Ensure markdown to HTML works as expected.
Repository: encode/django-rest-framework

Issue:
Makes it easy to change AuthToken model class when overriding built-in O...
Makes it easy to change AuthToken model class when overriding built-in ObtainAuthToken view.
ObtainAuthToken view has a `model` attribute, but it uses a Token class whatever in `post()` method.



Discussion:
I thought `.model` was deprecated in #1784. Why does Token view even have it?

Looks like some tweaks needed if this view (eg let's also use .is_valid(raise_exception=True)

You mean something simple like this?

```
class ObtainAuthToken(APIView):
    throttle_classes = ()
    permission_classes = ()
    parser_classes = (parsers.FormParser, parsers.MultiPartParser, parsers.JSONParser,)
    renderer_classes = (renderers.JSONRenderer,)
    serializer_class = AuthTokenSerializer

    def post(self, request):
        serializer = self.serializer_class(data=request.data)
        serializer.is_valid(raise_exception=True)
        user = serializer.validated_data['user']
        token, created = Token.objects.get_or_create(user=user)
        return Response({'token': token.key})


obtain_auth_token = ObtainAuthToken.as_view()
```

I don't think there's much we can do with the hardcoded `Token` model, as the serializer/view don't know how to create an instance. I read in #399 that you didn't want to use `CreateAPIView`. Still the same thoughts as of today?

> You mean something simple like this?

Exactly, yes.

I would drop the `serializer_class` attribute and instead just use `AuthTokenSerializer` in the `post` method directly. Anyone wanting to customize the view behavior should just do so explicitly.

> you didn't want to use CreateAPIView.

Probably simplest as it is, yup.


Resolving patch:
diff --git a/rest_framework/authtoken/views.py b/rest_framework/authtoken/views.py
--- a/rest_framework/authtoken/views.py
+++ b/rest_framework/authtoken/views.py
@@ -1,5 +1,4 @@
 from rest_framework.views import APIView
-from rest_framework import status
 from rest_framework import parsers
 from rest_framework import renderers
 from rest_framework.response import Response
@@ -12,16 +11,13 @@ class ObtainAuthToken(APIView):
     permission_classes = ()
     parser_classes = (parsers.FormParser, parsers.MultiPartParser, parsers.JSONParser,)
     renderer_classes = (renderers.JSONRenderer,)
-    serializer_class = AuthTokenSerializer
-    model = Token
 
     def post(self, request):
-        serializer = self.serializer_class(data=request.data)
-        if serializer.is_valid():
-            user = serializer.validated_data['user']
-            token, created = Token.objects.get_or_create(user=user)
-            return Response({'token': token.key})
-        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
+        serializer = AuthTokenSerializer(data=request.data)
+        serializer.is_valid(raise_exception=True)
+        user = serializer.validated_data['user']
+        token, created = Token.objects.get_or_create(user=user)
+        return Response({'token': token.key})
 
 
 obtain_auth_token = ObtainAuthToken.as_view()


Test patch:
Repository: encode/django-rest-framework

Issue:
Nested writable serializers validation in ModelSerializer.update method seems wrong
The `update` method on `ModelSerializer` makes sure that the data doesn't contain nested writable fields of the `BaseSerializer` variety, as per the documentation. However, it doesn't actually assert this by looking at the passed `validated_attrs`. Instead, it does this by looking at `self.fields`:

``` python
assert not any(
            isinstance(field, BaseSerializer) and not field.read_only
            for field in self.fields.values()
```

This means that even if we pop() the data of the nested serializer (as shown in the changelog example), the assertion still fails. This makes it necessary to call explicitly delete the field from `self.fields`:

``` python
def update(self, instance, validated_attrs):
        try:
            # Removing user data - not wanted for an update.
            validated_attrs.pop('user')
            self.fields.__delitem__('user') # This shouldn't be necessary.
        except KeyError:
            pass

        return super(CustomerSerializer, self).update(instance=instance, validated_attrs=validated_attrs)
```

By the time it gets to `update`, the data has already been validated. So you should be able to assume that any fields not present can be ignored, no?

In short, I'd say that it shouldn't trigger the error if the field isn't in the `validated_attrs`.



Discussion:
Okay, didn't consider the case of making a change to `validated_attrs` and then calling into the implementation with `super`.

I'm just lazy and wanted to avoid having to write my own update code. Sorry!


Resolving patch:
diff --git a/rest_framework/serializers.py b/rest_framework/serializers.py
--- a/rest_framework/serializers.py
+++ b/rest_framework/serializers.py
@@ -633,8 +633,8 @@ def create(self, validated_attrs):
         # If we don't do this explicitly they'd likely get a confusing
         # error at the point of calling `Model.objects.create()`.
         assert not any(
-            isinstance(field, BaseSerializer) and not field.read_only
-            for field in self.fields.values()
+            isinstance(field, BaseSerializer) and (key in validated_attrs)
+            for key, field in self.fields.items()
         ), (
             'The `.create()` method does not suport nested writable fields '
             'by default. Write an explicit `.create()` method for serializer '
@@ -681,8 +681,8 @@ def create(self, validated_attrs):
 
     def update(self, instance, validated_attrs):
         assert not any(
-            isinstance(field, BaseSerializer) and not field.read_only
-            for field in self.fields.values()
+            isinstance(field, BaseSerializer) and (key in validated_attrs)
+            for key, field in self.fields.items()
         ), (
             'The `.update()` method does not suport nested writable fields '
             'by default. Write an explicit `.update()` method for serializer '


Test patch:
Repository: encode/django-rest-framework

Issue:
Improve error checking for nested writes.
See https://github.com/tomchristie/django-rest-framework/pull/2196#issuecomment-66818050

There are cases indicated as nested writes that actually are not. Typically won't happen but case linked above is an example of how it can.

We could additionally only fail if the validated date element is a dict or list. This would improve the robustness of the check.



Discussion:

Resolving patch:
diff --git a/rest_framework/serializers.py b/rest_framework/serializers.py
--- a/rest_framework/serializers.py
+++ b/rest_framework/serializers.py
@@ -611,6 +611,7 @@ def raise_errors_on_nested_writes(method_name, serializer, validated_data):
     #     profile = ProfileSerializer()
     assert not any(
         isinstance(field, BaseSerializer) and (key in validated_data)
+        and isinstance(validated_data[key], (list, dict))
         for key, field in serializer.fields.items()
     ), (
         'The `.{method_name}()` method does not support writable nested'
@@ -630,6 +631,7 @@ def raise_errors_on_nested_writes(method_name, serializer, validated_data):
     #     address = serializer.CharField('profile.address')
     assert not any(
         '.' in field.source and (key in validated_data)
+        and isinstance(validated_data[key], (list, dict))
         for key, field in serializer.fields.items()
     ), (
         'The `.{method_name}()` method does not support writable dotted-source '


Test patch: