-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Do not treat missing non-form data as empty dict #7199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -341,7 +341,7 @@ def _parse(self): | |
if media_type and is_form_media_type(media_type): | ||
empty_data = QueryDict('', encoding=self._request._encoding) | ||
else: | ||
empty_data = {} | ||
empty_data = api_settings.DEFAULT_MISSING_DATA | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. instead of exposing a new API can we just handle the empty data as None value instead of dict? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That was my initial proposal, and I have no objection to doing so. However, please see the discussion in #7195 (comment) (and the context that led up to this post). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what I am suggesting you is based on this comment #7199 (comment) as Tom is reluctant to introduce new API surface to the framework. I saw those discussions as well and do agree with most of them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, but Tom was even more reluctant to silently change the behavior ("too big of a behavior change" in this earlier comment). He seemed to be more ok with adding the setting, see #7195 (comment). I have no stakes, and either way is fine for me. It's just think that this question needs clarification between Tom and you, and I can't answer it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @tomchristie need your input here There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. should we try empty_data = {} or None? and get rid of a new settings? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't understand how we could "try" Tom has already given his input and agreed to the above code change, see his thumbs-up on #7195 (comment) and the next comment, #7195 (comment). |
||
empty_files = MultiValueDict() | ||
return (empty_data, empty_files) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe let's call this something like
EMPTY_REQUEST_DATA
?The
DEFAULT_XYZ
cases make sense because they're things that can be overridden, and are populating the default value. In this case it's not a default case that can be overridden, but rather the base case that it always used if there's an empty request.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to take feedback on alternate naming choices, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose "missing" as opposed to "empty" because conventional usage of the word "empty" would suggest that a request body of
""
,[]
or{}
is also empty (len(request.data) == 0
after deserialization). I feared that if we call it "EMPTY_DATA", one may think that any "empty-like" payload would be coerced into this value. -- However, I don't feel strongly, as long as the documentation is clear.Regarding whether it is a default: If by "override", you mean overriding by view attribute or similar, fair enough; one could also argue that the client can override it (by sending data), which would warrant the name
DEFAULT_DATA
orDEFAULT_REQUEST_DATA
.(Also, it's conceivable that there would a view attribute to override this setting at some point, although right now the request would not have the corresponding context.)
Having said all this, I think my favorite would be
DEFAULT_REQUEST_DATA
, as I think it is accurate and future-proof. But in the end, I don't have any stakes in the naming, and will be ok with whatever you prefer.