docs: improve docstring for get_serializer to clarify behavior #9870
+24
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: Before submitting a code change, please review our contributing guidelines.
Description
Summary
This PR adds missing docstrings to two internal helper functions in serializers.py that are central to serializer validation and error handling.
The changes are documentation-only and do not alter runtime behavior.
Details
The following docstrings were added:
as_serializer_error
Documents the function’s role in normalizing Django and DRF ValidationError instances into the serializer .errors format.
Clarifies the expected structure of field and non-field errors returned by the function.
raise_errors_on_nested_writes
Replaces inline explanatory comments with a formal docstring.
Explains why writable nested and dotted-source fields are intentionally unsupported by default.
Documents when the helper is invoked and what is expected of developers when overriding create() / update().
These helpers are frequently encountered when extending or debugging serializers, but previously lacked API-level documentation.
Motivation
Serializer error handling and nested write behavior are common sources of confusion for contributors and advanced users. Providing clear docstrings improves:
Code readability and maintainability
IDE introspection and contributor onboarding
Alignment between implementation and documented behavior
Scope
Documentation-only change
No functional or behavioral modifications
No test changes required
Checklist