It’s a bit of a mystery, isn’t it? Several superficially plausible theories turn out to be wrong on investigation:
-
So that the
POST
object doesn’t have to implement mutation methods? No: thePOST
object belongs to thedjango.http.QueryDict
class, which implements a full set of mutation methods including__setitem__
,__delitem__
,pop
andclear
. It implements immutability by checking a flag when you call one of the mutation methods. And when you call thecopy
method you get anotherQueryDict
instance with the mutable flag turned on. -
For performance improvement? No: the
QueryDict
class gains no performance benefit when the mutable flag is turned off. -
So that the
POST
object can be used as a dictionary key? No:QueryDict
objects are not hashable. -
So that the
POST
data 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 viaMultiPartParser
formultipart
responses. -
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 multipart
, then 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-multipart
requests.