default field argument behaves incorrectly when partial=True

[r-thomson]

If you look at the official documentation for the default argument:

When serializing the instance, default will be used if the object attribute or dictionary key is not present in the instance.

When performing a read or a create, this works as expected:

from rest_framework import serializers
from types import SimpleNamespace


class TestSerializer(serializers.Serializer):
    field = serializers.CharField(read_only=True, default='default value')

    def create(self, validated_data):
        return SimpleNamespace()
    
    def update(self, instance, validated_data):
        return instance

>>> TestSerializer(SimpleNamespace()).data
{'field': 'default value'}

>>> ser = TestSerializer(data={})
>>> ser.is_valid()
>>> ser.data
{'field': 'default value'}

However, when performing a partial update, this doesn't work— the field is not included in the output.

>>> ser = TestSerializer(instance=SimpleNamespace(), data={}, partial=True)
>>> ser.is_valid()
>>> ser.data
{}

This results in your API's public interface unexpectedly changing when performing partial updates.

This is caused by a bug in Field.get_attribute(), which calls self.get_default().

django-rest-framework/rest_framework/fields.py

Lines 450 to 452 in d6e11ec

	except (KeyError, AttributeError) as exc:
	if self.default is not empty:
	return self.get_default()

However, the implementation for Field.get_default() raises SkipField() whenever partial is True.

django-rest-framework/rest_framework/fields.py

Lines 481 to 483 in d6e11ec

	if self.default is empty or getattr(self.root, 'partial', False):
	# No default, or this is a partial update.
	raise SkipField()

[browniebroke]

The link you shared from the docs has the following paragraph:

The default is not applied during partial update operations. In the partial update case only fields that are provided in the incoming data will have a validated value returned.

Which seems to document this exact behaviour

[r-thomson]

My interpretation of that was that the behavior applies during deserialization (to_internal_value), not during serialization (to_representation).

Otherwise, the behavior is very unintuitive in the case of e.g. a read-only field, where your API schema changes between a PUT and a PATCH.