django - почему объект request.POST неизменен?

Как видно из названия, почему ребята из Django решили реализовать объект request.POST с помощью querydict (что, конечно, в свою очередь, делает все это неизменным?)

Я знаю, что вы можете изменить это, сделав копию данных публикации

post = request.POST.copy()

но зачем это делать? Конечно, было бы проще просто разрешить этому объекту быть изменяемым? Или он используется по какой-то другой причине, которая может вызвать проблемы?

Это немного загадка, правда? Несколько внешне правдоподобных теорий в ходе расследования оказываются неверными:

1. Чтобы POSTобъекту не пришлось реализовывать методы мутации? Нет: POSTобъект принадлежит к django.http.QueryDictклассу , который реализует полный набор методов мутации , включая __setitem__, __delitem__, popи clear. Он реализует неизменяемость, проверяя флаг при вызове одного из методов мутации. И когда вы вызываете copyметод, вы получаете еще один QueryDictэкземпляр с включенным изменяемым флагом.

2. Для повышения производительности? Нет: QueryDictкласс не получает выигрыша в производительности, когда изменяемый флаг отключен.

3. Чтобы POSTобъект можно было использовать как ключ словаря? Нет: QueryDictобъекты не хешируются.

4. Чтобы POSTданные можно было собирать лениво (без необходимости читать весь ответ), как здесь заявлено ? Я не вижу свидетельств этого в коде: насколько я могу судить, всегда читается весь ответ, либо напрямую , либо через MultiPartParserдля multipartответов.

5. Чтобы защитить вас от ошибок программирования? Я видел, как это утверждается, но я никогда не видел хорошего объяснения того, что это за ошибки, и как неизменность защищает вас от них.

В любом случае, POSTэто не всегда неизменны : когда ответ multipart, то POSTизменчиво. Похоже, это ставит под сомнение большинство теорий, которые вы можете придумать. (Если это поведение не является недосмотром.)

Таким образом, я не вижу в Django четкого обоснованияPOST неизменности объекта для не- multipartзапросов.

Если запрос был результатом Джанго formпредставления, то разумно для POST быть immutableдля обеспечения целостности данных между формой представлением и формой проверкой . Однако, если запрос не был отправлен через отправку Django form, то POST - mutableэто отсутствие проверки формы.

Вы всегда можете сделать что-то вроде этого: (согласно комментарию @ leo-the-manic )

#  .....
mutable = request.POST._mutable
request.POST._mutable = True
request.POST['some_data'] = 'test data'
request.POST._mutable = mutable
# ......

Обновление :

Гарет Рис был прав в том, что пункты 1 и 3 в данном случае недействительны. Хотя я думаю, что пункты 2 и 4 все еще в силе, поэтому я оставлю здесь тезисы.

(Я заметил, что request.POSTобъект как Pyramid (Pylon), так и Django является некоторой формой MultiDict. Так что, возможно, это более распространенная практика, чем создание request.POSTнеизменяемого.)

Я не могу говорить за ребят из Django, хотя мне кажется, что это могло произойти по некоторым из следующих причин:

1. Исполнение . неизменяемые объекты «быстрее», чем изменяемые, в том смысле, что они допускают существенную оптимизацию. Неизменяемость объекта означает, что мы можем выделить для него пространство во время создания , и требования к пространству не меняются. Он также имеет такие вещи, как эффективность копирования и эффективность сравнения. Изменить : это не так,QueryDictкак указал Гарет Рис.
2. В случае request.POST, кажется, что никакие действия на стороне сервера не должны изменять данные запроса . И, следовательно, неизменяемые объекты больше подходят, не говоря уже о том, что они имеют существенное преимущество в производительности.
3. Неизменяемые объекты могут использоваться как dictключи, что, как я полагаю, может быть очень полезно где-нибудь в Django .. Редактировать : моя ошибка, неизменяемость не подразумевает напрямую хеширование ; Однако хешируемые объекты обычно также неизменяемы .
4. Когда вы переходите request.POST(особенно к сторонним плагинам и выходят), вы можете ожидать, что этот объект запроса от пользователя останется неизменным.

В каком-то смысле эти причины также являются общими ответами на вопрос «неизменный vs изменчивый?» вопрос. Я уверен, что в случае с Django существует гораздо больше соображений по поводу дизайна, чем указано выше.

Мне нравится, что по умолчанию он неизменен. Как уже указывалось, вы можете сделать его изменяемым, если вам нужно, но вы должны четко указать на это. Это похоже на «Я знаю, что могу превратить отладку моей формы в кошмар, но я знаю, что делаю сейчас».

Я нашел это в комментарии к ответу на стек https://stackoverflow.com/a/2339963

И он должен быть неизменным, чтобы его можно было построить лениво. Копия заставляет получить все данные POST. До копии может быть получено не все. Кроме того, чтобы многопоточный сервер WSGI работал достаточно хорошо, полезно, если он является неизменным.

Обратите внимание: multipartзапросы неизменны с Django 1.11 https://github.com/django/django/blob/stable/1.11.x/django/http/multipartparser.py#L292

В предыдущих версиях они были изменяемыми.