django – why is the request.POST object immutable?
As the title asks, why did the Django guys decide to implement the request.POST object with a querydict (which, of course, in turn, makes the whole thing immutable?) I know you can mutify it by making a copy of the post data post = request.POST.copy() but why do this? Surely it would be simpler just to allow the thing to be mutable anyway? Or is it being used for some other reason too which might cause issue?
It’s a bit of a mystery, isn’t it? Several superficially plausible theories turn out to be wrong on investigation:
So that the
POSTobject doesn’t have to implement mutation methods? No: the
POSTobject belongs to the
django.http.QueryDictclass, which implements a full set of mutation methods including
clear. It implements immutability by checking a flag when you call one of the mutation methods. And when you call the
copymethod you get another
QueryDictinstance with the mutable flag turned on.
For performance improvement? No: the
QueryDictclass gains no performance benefit when the mutable flag is turned off.
So that the
POSTobject can be used as a dictionary key? No:
QueryDictobjects are not hashable.
So that the
POSTdata can be built lazily (without committing to read the whole response), as claimed here? I see no evidence of this in the code: as far as I can tell, the whole of the response is always read, either directly, or via
To protect you against programming errors? I’ve seen this claimed, but I’ve never seen a good explanation of what these errors are, and how immutability protects you against them.
In any case,
POST is not always immutable: when the response is
POST is mutable. This seems to put the kibosh on most theories you might think of. (Unless this behaviour is an oversight.)
In summary, I can see no clear rationale in Django for the
POST object to be immutable for non-
If the request was the result of a Django
form submission, then it is reasonable for POST being
immutable to ensure the integrity of the data between the form submission and the form validation. However, if the request was not sent via a Django
form submission, then POST is
mutable as there is no form validation.
You can always do something like this: (as per @leo-the-manic’s comment)
# ..... mutable = request.POST._mutable request.POST._mutable = True request.POST['some_data'] = 'test data' request.POST._mutable = mutable # ......
Gareth Rees was right that point 1 & 3 were not valid in this case. Though I think point 2 and 4 are still valid, therefore I will leave theses here.
(I noticed that the
request.POST object of both Pyramid(Pylon) and Django is some form of
MultiDict. So perhaps it is a more common practice than making
I can’t speak for the Django guys, though it seems to me that it could because of some of these reasons:
Performence. immutable objects are “faster” over mutable ones in that they allow substantial optimizations. An object is immutable means that we can allocate space for it at creation time, and the space requirements are not changing. It also has things like copy efficiency and comparison efficiency because of it.
Edit: this is not the case for
QueryDictas Gareth Rees pointed out.
- In the case of
request.POST, it seems no activity in the server side should need to alter the request’s data. And hence immutable objects are more suited, not to mention they have substantial performence advantage.
Immutable objects can be used as
dictkeys, which I suppose could be very useful somewhere in Django..
Edit: my mistake, immutable does not directly imply hashable; hashable objects however, are typically immutable as well.
- When you pass around
request.POST(especially to third-party plugins and out), you can expect that this request object from the user will remain unchanged.
In some way these reasons are also generic answers to “immutable vs mutable?” question. I am certain there are much more design considerations than above in the Django case.
I like it being immutable by default.
As pointed out you can make it mutable if you need to but you must be explicit about it.
It is like ‘I know that I can make my form debugging a nightmare but I know what I am doing now.’
I found this in a comment on Stack Answer https://stackoverflow.com/a/2339963
And it must be immutable so that it can be built lazily. The copy forces getting all the POST data. Until the copy, it may not all be fetched. Further, for a multi-threaded WSGI server to work reasonably well, it’s helpful if this is immutable
multipart request are immutable since Django 1.11
They were mutable in previous versions.
- Database Administration Tutorials
- Programming Tutorials & IT News
- Linux & DevOps World
- Entertainment & General News
- Games & eSport