Add multipart_parser_class attribute to HttpRequest for pluggable multipart parsing
Problem
Django's parse_file_upload() hardcodes MultiPartParser, making it hard
to swap in faster implementations.
Proposed Solution
As discussed with the steering council and Carlton Gibson on the forum:
- Add
multipart_parser_class class attribute to HttpRequest (defaulting to MultiPartParser)
- Modify
parse_file_upload() to use self.multipart_parser_class instead of direct import
- Ensure uniform parser interface:
__init__(META, input_data, upload_handlers, encoding)
with parse() returning (POST, FILES)
Usage
Users can subclass HttpRequest and override multipart_parser_class to use
faster parsers.
Benefits
- Immediate performance improvements for those who need them
- Stepping stone toward DEP 17 https://github.com/django/deps/pull/88 (pluggable content type parsers)
- Minimal change
- Follows proven pattern from Django REST Framework's
parser_classes
Forum Discussion
https://github.com/django/new-features/issues/105
Change History
(12)
| Triage Stage: |
Unreviewed → Accepted
|
| Needs documentation: |
unset
|
| Patch needs improvement: |
set
|
| Patch needs improvement: |
unset
|
| Triage Stage: |
Accepted → Ready for checkin
|
| Patch needs improvement: |
set
|
| Triage Stage: |
Ready for checkin → Accepted
|
| Patch needs improvement: |
unset
|
| Triage Stage: |
Accepted → Ready for checkin
|
| Resolution: |
→ fixed
|
| Status: |
assigned → closed
|
Thanks for opening the ticket and for following the prior discussion!
The DRF comparison is useful as prior art, but this does not add view-level
parser_classes, keeping the scope intentionally small. Configurability via a customHttpRequestsubclass is sufficient at this stage and keeps the change minimal.Proceeding with a PR along these lines sounds good, looking forward to that!