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

Issue:
Better errors when serializer has incorrectly named field.
If I have a mistake in my model serializer where there's a serializer field name that isn't mapped to a field in the model, e.g. 

```
class MySerializer(serializers.ModelSerializer):
    bad_serializer_field_name = MyCustomSerializer()
```

then the serializer fails silently and by returning no  no data.  It would be nice for debugging if the serialization process would issue a warning.



Discussion:

Resolving patch:
diff --git a/rest_framework/fields.py b/rest_framework/fields.py
--- a/rest_framework/fields.py
+++ b/rest_framework/fields.py
@@ -274,7 +274,23 @@ def get_attribute(self, instance):
         Given the *outgoing* object instance, return the primitive value
         that should be used for this field.
         """
-        return get_attribute(instance, self.source_attrs)
+        try:
+            return get_attribute(instance, self.source_attrs)
+        except (KeyError, AttributeError) as exc:
+            msg = (
+                'Got {exc_type} when attempting to get a value for field '
+                '`{field}` on serializer `{serializer}`.\nThe serializer '
+                'field might be named incorrectly and not match '
+                'any attribute or key on the `{instance}` instance.\n'
+                'Original exception text was: {exc}.'.format(
+                    exc_type=type(exc).__name__,
+                    field=self.field_name,
+                    serializer=self.parent.__class__.__name__,
+                    instance=instance.__class__.__name__,
+                    exc=exc
+                )
+            )
+            raise type(exc)(msg)
 
     def get_default(self):
         """


Test patch:
diff --git a/tests/test_serializer.py b/tests/test_serializer.py
--- a/tests/test_serializer.py
+++ b/tests/test_serializer.py
@@ -1,3 +1,4 @@
+from __future__ import unicode_literals
 from rest_framework import serializers
 import pytest
 
@@ -175,3 +176,24 @@ def test_nested_serialize(self):
         instance = {'a': 1, 'b': 2, 'c': 3, 'd': 4}
         serializer = self.Serializer(instance)
         assert serializer.data == self.data
+
+
+class TestIncorrectlyConfigured:
+    def test_incorrect_field_name(self):
+        class ExampleSerializer(serializers.Serializer):
+            incorrect_name = serializers.IntegerField()
+
+        class ExampleObject:
+            def __init__(self):
+                self.correct_name = 123
+
+        instance = ExampleObject()
+        serializer = ExampleSerializer(instance)
+        with pytest.raises(AttributeError) as exc_info:
+            serializer.data
+        msg = str(exc_info.value)
+        assert msg.startswith(
+            "Got AttributeError when attempting to get a value for field `incorrect_name` on serializer `ExampleSerializer`.\n"
+            "The serializer field might be named incorrectly and not match any attribute or key on the `ExampleObject` instance.\n"
+            "Original exception text was:"
+        )
Repository: encode/django-rest-framework

Issue:
Fix empty HTML values when a default is provided.
Attribute 'default_empty_html' by BooleanField/CharField ignores 'default'/'allow_blank'.
For example, if we get empty data, all Boolean instance has False, all CharField has ''.

```
  for field in fields:
        validate_method = getattr(self, 'validate_' + field.field_name, None)
        primitive_value = field.get_value(data)
        try:
            validated_value = field.run_validation(primitive_value)
        ...

  def get_value(self, dictionary):
        ...
        if self.field_name not in dictionary:
            ....
            return self.default_empty_html
        ...
```

I guess 'default_empty_html' should be empty.



Discussion:

Resolving patch:
diff --git a/rest_framework/fields.py b/rest_framework/fields.py
--- a/rest_framework/fields.py
+++ b/rest_framework/fields.py
@@ -185,8 +185,13 @@ def __init__(self, read_only=False, write_only=False,
         self.allow_null = allow_null
 
         if allow_null and self.default_empty_html is empty:
+            # HTML input cannot represent `None` values, so we need to
+            # forcibly coerce empty HTML values to `None` if `allow_null=True`.
             self.default_empty_html = None
 
+        if default is not empty:
+            self.default_empty_html = default
+
         if validators is not None:
             self.validators = validators[:]
 


Test patch:
diff --git a/tests/test_fields.py b/tests/test_fields.py
--- a/tests/test_fields.py
+++ b/tests/test_fields.py
@@ -215,6 +215,26 @@ class MockHTMLDict(dict):
         assert serializer.validated_data == {'archived': False}
 
 
+class TestCharHTMLInput:
+    def setup(self):
+        class TestSerializer(serializers.Serializer):
+            message = serializers.CharField(default='happy')
+        self.Serializer = TestSerializer
+
+    def test_empty_html_checkbox(self):
+        """
+        HTML checkboxes do not send any value, but should be treated
+        as `False` by BooleanField.
+        """
+        # This class mocks up a dictionary like object, that behaves
+        # as if it was returned for multipart or urlencoded data.
+        class MockHTMLDict(dict):
+            getlist = None
+        serializer = self.Serializer(data=MockHTMLDict())
+        assert serializer.is_valid()
+        assert serializer.validated_data == {'message': 'happy'}
+
+
 class TestCreateOnlyDefault:
     def setup(self):
         default = serializers.CreateOnlyDefault('2001-01-01')
Repository: encode/django-rest-framework

Issue:
PaginationSerializer hardcoded to use ListSerializer
To me it feels like it should use Meta.list_serializer_class of the object serializer if it is defined instead.

``` patch
diff --git a/rest_framework/pagination.py b/rest_framework/pagination.py
index fb45128..94c2f2d 100644
--- a/rest_framework/pagination.py
+++ b/rest_framework/pagination.py
@@ -68,7 +68,12 @@ class BasePaginationSerializer(serializers.Serializer):
         except AttributeError:
             object_serializer = DefaultObjectSerializer

-        self.fields[results_field] = serializers.ListSerializer(
+        try:
+            list_serializer = object_serializer.Meta.list_serializer_class
+        except AttributeError:
+            list_serializer = serializers.ListSerializer
+
+        self.fields[results_field] = list_serializer(
             child=object_serializer(),
             source='object_list'
         )
```



Discussion:
Improvements to the pagination API will come in 3.1. Tracking against https://github.com/tomchristie/django-rest-framework/issues/1169

Actually this could still be valid in the meantime.

It seems to solve my immediate problem anyway.


Resolving patch:
diff --git a/rest_framework/pagination.py b/rest_framework/pagination.py
--- a/rest_framework/pagination.py
+++ b/rest_framework/pagination.py
@@ -68,7 +68,12 @@ def __init__(self, *args, **kwargs):
         except AttributeError:
             object_serializer = DefaultObjectSerializer
 
-        self.fields[results_field] = serializers.ListSerializer(
+        try:
+            list_serializer_class = object_serializer.Meta.list_serializer_class
+        except AttributeError:
+            list_serializer_class = serializers.ListSerializer
+
+        self.fields[results_field] = list_serializer_class(
             child=object_serializer(),
             source='object_list'
         )


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

Issue:
Browsable API can't resolve URLs for HyperlinkedRelatedFields when using versioning
Very similar to #2455.

When the Browsable API clones requests to check the permissions on other methods, it doesn't clone the `versioning_scheme` attribute and this causes reverse lookups to fail.

```
ImproperlyConfigured: Could not resolve URL for hyperlinked relationship using view name "aggregator-detail". You may have failed to include the related model in your API, or incorrectly configured the `lookup_field` attribute on this field.
```



Discussion:

Resolving patch:
diff --git a/rest_framework/request.py b/rest_framework/request.py
--- a/rest_framework/request.py
+++ b/rest_framework/request.py
@@ -109,6 +109,8 @@ def clone_request(request, method):
         ret.accepted_media_type = request.accepted_media_type
     if hasattr(request, 'version'):
         ret.version = request.version
+    if hasattr(request, 'versioning_scheme'):
+        ret.versioning_scheme = request.versioning_scheme
     return ret
 
 


Test patch:
diff --git a/tests/test_metadata.py b/tests/test_metadata.py
--- a/tests/test_metadata.py
+++ b/tests/test_metadata.py
@@ -1,5 +1,5 @@
 from __future__ import unicode_literals
-from rest_framework import exceptions, serializers, status, views
+from rest_framework import exceptions, serializers, status, views, versioning
 from rest_framework.request import Request
 from rest_framework.renderers import BrowsableAPIRenderer
 from rest_framework.test import APIRequestFactory
@@ -183,3 +183,18 @@ def get_serializer(self):
 
         view = ExampleView.as_view()
         view(request=request)
+
+    def test_bug_2477_clone_request(self):
+        class ExampleView(views.APIView):
+            renderer_classes = (BrowsableAPIRenderer,)
+
+            def post(self, request):
+                pass
+
+            def get_serializer(self):
+                assert hasattr(self.request, 'versioning_scheme')
+                return serializers.Serializer()
+
+        scheme = versioning.QueryParameterVersioning
+        view = ExampleView.as_view(versioning_class=scheme)
+        view(request=request)
Repository: encode/django-rest-framework

Issue:
Validators are old-style classes.
This means `super` cannot be used in a subclassed `Valdiator` in python 2.



Discussion:
Sure. Feel free to pull request it.


Resolving patch:
diff --git a/rest_framework/validators.py b/rest_framework/validators.py
--- a/rest_framework/validators.py
+++ b/rest_framework/validators.py
@@ -13,7 +13,7 @@
 from rest_framework.utils.representation import smart_repr
 
 
-class UniqueValidator:
+class UniqueValidator(object):
     """
     Validator that corresponds to `unique=True` on a model field.
 
@@ -67,7 +67,7 @@ def __repr__(self):
         ))
 
 
-class UniqueTogetherValidator:
+class UniqueTogetherValidator(object):
     """
     Validator that corresponds to `unique_together = (...)` on a model class.
 
@@ -155,7 +155,7 @@ def __repr__(self):
         ))
 
 
-class BaseUniqueForValidator:
+class BaseUniqueForValidator(object):
     message = None
     missing_message = _('This field is required.')
 


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

Issue:
LimitOffsetPagination raises Type error if PAGE_SIZE not set
In 3.1.0 if you do not have PAGE_SIZE set you get a TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'.

I believe a friendlier message would be useful in this case. I was going to submit a patch but was not sure exactly how you would like to handle this.

Exception Type: TypeError
Exception Value:  
unsupported operand type(s) for +: 'int' and 'NoneType'
Exception Location: /work/virtual/skysql_upgrade/local/lib/python2.7/site-packages/rest_framework/pagination.py in paginate_queryset, line 396



Discussion:

Resolving patch:
diff --git a/rest_framework/pagination.py b/rest_framework/pagination.py
--- a/rest_framework/pagination.py
+++ b/rest_framework/pagination.py
@@ -388,6 +388,9 @@ class LimitOffsetPagination(BasePagination):
 
     def paginate_queryset(self, queryset, request, view=None):
         self.limit = self.get_limit(request)
+        if self.limit is None:
+            return None
+
         self.offset = self.get_offset(request)
         self.count = _get_count(queryset)
         self.request = request
@@ -491,6 +494,9 @@ class CursorPagination(BasePagination):
     template = 'rest_framework/pagination/previous_and_next.html'
 
     def paginate_queryset(self, queryset, request, view=None):
+        if self.page_size is None:
+            return None
+
         self.base_url = request.build_absolute_uri()
         self.ordering = self.get_ordering(request, queryset, view)
 


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

Issue:
STATUS_CODE_TEXT was removed from django in trac ticket #24137
I'm getting an `ImportError` when using django 1.8 beta and rest framework 3.1.0

```
File "/<omitted>/rest_framework/response.py", line 8, in <module>
    from django.core.handlers.wsgi import STATUS_CODE_TEXT
ImportError: cannot import name 'STATUS_CODE_TEXT'
```



Discussion:
Link to relevant ticket https://code.djangoproject.com/ticket/24137. In summary we should probably be able to do something like in [response.py](https://github.com/tomchristie/django-rest-framework/blob/a89e05dc73e2c532372b1f9c51f38100f7f795f6/rest_framework/response.py#L80):

``` python
from django.utils.six.moves.http_client import responses
return responses.get(self.status_code, '')
```


Resolving patch:
diff --git a/rest_framework/response.py b/rest_framework/response.py
--- a/rest_framework/response.py
+++ b/rest_framework/response.py
@@ -5,7 +5,7 @@
 The appropriate renderer is called during Django's template response rendering.
 """
 from __future__ import unicode_literals
-from django.core.handlers.wsgi import STATUS_CODE_TEXT
+from django.utils.six.moves.http_client import responses
 from django.template.response import SimpleTemplateResponse
 from django.utils import six
 
@@ -77,7 +77,7 @@ def status_text(self):
         """
         # TODO: Deprecate and use a template tag instead
         # TODO: Status code text for RFC 6585 status codes
-        return STATUS_CODE_TEXT.get(self.status_code, '')
+        return responses.get(self.status_code, '')
 
     def __getstate__(self):
         """


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

Issue:
IntegerField.to_internal_value coerces decimal to integer; should fail
The to_internal_value method coerces data to an int, so when a float/decimal is passed, the int value is saved, rather than raising an exception.



Discussion:

Resolving patch:
diff --git a/rest_framework/fields.py b/rest_framework/fields.py
--- a/rest_framework/fields.py
+++ b/rest_framework/fields.py
@@ -682,7 +682,7 @@ def to_internal_value(self, data):
             self.fail('max_string_length')
 
         try:
-            data = int(data)
+            data = int(re.compile(r'\.0*\s*$').sub('', str(data)))
         except (ValueError, TypeError):
             self.fail('invalid')
         return data


Test patch:
diff --git a/tests/test_fields.py b/tests/test_fields.py
--- a/tests/test_fields.py
+++ b/tests/test_fields.py
@@ -549,10 +549,13 @@ class TestIntegerField(FieldValues):
         1: 1,
         0: 0,
         1.0: 1,
-        0.0: 0
+        0.0: 0,
+        '1.0': 1
     }
     invalid_inputs = {
-        'abc': ['A valid integer is required.']
+        0.5: ['A valid integer is required.'],
+        'abc': ['A valid integer is required.'],
+        '0.5': ['A valid integer is required.']
     }
     outputs = {
         '1': 1,
Repository: encode/django-rest-framework

Issue:
exception_handler does not actually handle Django's built-in ValidationError
Unlike the documentation suggests, the function `exception_handler` does not actually handle Django's built-in ValidationError.

https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/views.py#L52



Discussion:
The docstring should be changed there, yes.
We handle django's built-in validation error in serializers, but not here.

Would you like a patch for the docstring?

```
We handle django's built-in validation error in serializers, but not here.
```

I am calling `Model.clean` in the serializer `update` and `create` functions but it does not catch django's validation errors. I had to resort to a custom exception handler. Am I missing something obvious?

The documentation speaks of having to code it yourself, but does not elaborate on how to do it.

> Would you like a patch for the docstring?

That'd be great - I'm happy for us just to drop any mention of Django's validation error there.

> I am calling Model.clean in the serializer update and create functions but it does not catch django's validation errors. I had to resort to a custom exception handler. Am I missing something obvious?

Typically you'd want to handle validation _prior_ to update or create.
In the case that you're using, yes you'll either need to catch and re-raise the exceptions as a handled type, or override the handler to deal with them itself.

Sadly, validation is also needed in the Django Admin panel. There is currently no easy way to share validation. There was, in DRF 2.4.4 :wink:  So we are stuck with validation-heavy models for a while.

Sure. :smile: There's some background info on _why_ we've taken a slightly different approach now here https://www.youtube.com/watch?v=3cSsbe-tA0E - and yes that does mean a  little more work if you're using both Django's validation style and REST framework together.


Resolving patch:
diff --git a/rest_framework/views.py b/rest_framework/views.py
--- a/rest_framework/views.py
+++ b/rest_framework/views.py
@@ -54,8 +54,7 @@ def exception_handler(exc, context):
     Returns the response that should be used for any given exception.
 
     By default we handle the REST framework `APIException`, and also
-    Django's built-in `ValidationError`, `Http404` and `PermissionDenied`
-    exceptions.
+    Django's built-in `Http404` and `PermissionDenied` exceptions.
 
     Any unhandled exceptions may return `None`, which will cause a 500 error
     to be raised.


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

Issue:
`max_decimal_places` in Decimal field are wrong calculated
We got an issue when number is formatted as `decimal.Decimal('2E+9')`.

How `DecimalField` counts decimals:

```
    sign, digittuple, exponent = value.as_tuple()
    decimals = abs(exponent)
```

However result of `decimal.Decimal('2E+9').as_tuple()[2]` is **9**, which is ok, but there are no decimal places in this number.

My solution is to not do `abs` and instead multiply by `-1`. 

I can prepare PR tonight if you think it is valid. 



Discussion:
So things that would help here:
- Any comparisons between what happens in Django core and what we do (if that's possible/relevant?)
- One or two example cases (In particular pull requests with failing test cases), and expected input/output values.


Resolving patch:
diff --git a/rest_framework/fields.py b/rest_framework/fields.py
--- a/rest_framework/fields.py
+++ b/rest_framework/fields.py
@@ -782,7 +782,8 @@ def to_internal_value(self, data):
             self.fail('invalid')
 
         sign, digittuple, exponent = value.as_tuple()
-        decimals = abs(exponent)
+        decimals = exponent * decimal.Decimal(-1) if exponent < 0 else 0
+
         # digittuple doesn't include any leading zeros.
         digits = len(digittuple)
         if decimals > digits:


Test patch:
diff --git a/tests/test_fields.py b/tests/test_fields.py
--- a/tests/test_fields.py
+++ b/tests/test_fields.py
@@ -647,6 +647,7 @@ class TestDecimalField(FieldValues):
         0: Decimal('0'),
         12.3: Decimal('12.3'),
         0.1: Decimal('0.1'),
+        '2E+2': Decimal('200'),
     }
     invalid_inputs = (
         ('abc', ["A valid number is required."]),
Repository: encode/django-rest-framework

Issue:
CharField: allow_blank=False in combination with trim_whitespace=True does not behave as expected
The two options can not be used in combination to raise a validation error if the incoming data purely consists of whitespace because `to_internal_value` is not applied before validation.

Is this something that could be changed? And is there a way for me to achieve this behaviour currently without writing custom validation?



Discussion:
Sounds like a totally valid improvement to make, to me.


Resolving patch:
diff --git a/rest_framework/fields.py b/rest_framework/fields.py
--- a/rest_framework/fields.py
+++ b/rest_framework/fields.py
@@ -580,7 +580,7 @@ def run_validation(self, data=empty):
         # Test for the empty string here so that it does not get validated,
         # and so that subclasses do not need to handle it explicitly
         # inside the `to_internal_value()` method.
-        if data == '':
+        if data == '' or (self.trim_whitespace and six.text_type(data).strip() == ''):
             if not self.allow_blank:
                 self.fail('blank')
             return ''


Test patch:
diff --git a/tests/test_fields.py b/tests/test_fields.py
--- a/tests/test_fields.py
+++ b/tests/test_fields.py
@@ -461,6 +461,13 @@ def test_trim_whitespace_disabled(self):
         field = serializers.CharField(trim_whitespace=False)
         assert field.to_internal_value(' abc ') == ' abc '
 
+    def test_disallow_blank_with_trim_whitespace(self):
+        field = serializers.CharField(allow_blank=False, trim_whitespace=True)
+
+        with pytest.raises(serializers.ValidationError) as exc_info:
+            field.run_validation('   ')
+        assert exc_info.value.detail == ['This field may not be blank.']
+
 
 class TestEmailField(FieldValues):
     """
Repository: encode/django-rest-framework

Issue:
Cursor pagination page size
`page_size` customization on per query basis through `page_size_query_param` and `max_page_size` parameters.

Spin-off of #3033



Discussion:

Resolving patch:
diff --git a/rest_framework/pagination.py b/rest_framework/pagination.py
--- a/rest_framework/pagination.py
+++ b/rest_framework/pagination.py
@@ -455,7 +455,8 @@ class CursorPagination(BasePagination):
     template = 'rest_framework/pagination/previous_and_next.html'
 
     def paginate_queryset(self, queryset, request, view=None):
-        if self.page_size is None:
+        page_size = self.get_page_size(request)
+        if not page_size:
             return None
 
         self.base_url = request.build_absolute_uri()
@@ -490,8 +491,8 @@ def paginate_queryset(self, queryset, request, view=None):
         # If we have an offset cursor then offset the entire page by that amount.
         # We also always fetch an extra item in order to determine if there is a
         # page following on from this one.
-        results = list(queryset[offset:offset + self.page_size + 1])
-        self.page = list(results[:self.page_size])
+        results = list(queryset[offset:offset + page_size + 1])
+        self.page = list(results[:page_size])
 
         # Determine the position of the final item following the page.
         if len(results) > len(self.page):
@@ -530,6 +531,9 @@ def paginate_queryset(self, queryset, request, view=None):
 
         return self.page
 
+    def get_page_size(self, request):
+        return self.page_size
+
     def get_next_link(self):
         if not self.has_next:
             return None


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

Issue:
DjangoObjectPermissionsFilter broken by guardian 1.3 (devel)
The guardian shortcut "get_objects_for_user" uses accept_global_perms=True as default, which means that if you have a group that has view permission for ModelClass, and then filter on the objects, you will get ALL objects.

Easy way to fix this is to return guardian.shortcuts.get_objects_for_user(user, permission, queryset, accept_global_perms=False) instead.



Discussion:

Resolving patch:
diff --git a/rest_framework/filters.py b/rest_framework/filters.py
--- a/rest_framework/filters.py
+++ b/rest_framework/filters.py
@@ -198,4 +198,7 @@ def filter_queryset(self, request, queryset, view):
             'model_name': get_model_name(model_cls)
         }
         permission = self.perm_format % kwargs
-        return guardian.shortcuts.get_objects_for_user(user, permission, queryset)
+        if guardian.VERSION >= (1, 3):
+            # Maintain behavior compatibility with versions prior to 1.3
+            extra = {'accept_global_perms': False}
+        return guardian.shortcuts.get_objects_for_user(user, permission, queryset, **extra)


Test patch: