django - чому об'єкт request.POST незмінний?

Як заголовок запитує, чому хлопці Django вирішили реалізувати об'єкт request.POST із запитом (що, звичайно, в свою чергу, робить все це непорушним?)

Я знаю, що ви можете пошкодити це, зробивши копію даних публікації

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є змінною. Це, здається, ставить кібош на більшість теорій, про які ви можете подумати. (Якщо ця поведінка не є недоглядом.)

Підсумовуючи, я не бачу чіткого обгрунтування в Джанго, щоб POSTоб'єкт був непорушним для не multipartзапитів.

Якщо запит був результатом formподання Django , тоді POST доцільно immutableзабезпечити цілісність даних між подачею форми та валідацією форми . Однак якщо запит не був надісланий через 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об'єктом і Піраміди (Пілона), і Джанго є якась форма MultiDict. Тож, можливо, це є звичайнішою практикою, ніж робити request.POSTнепорушним.)

Я не можу говорити за хлопців Джанго, хоча мені здається, що це могло через деякі з цих причин:

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

У чомусь ці причини також є загальними відповідями на "непорушний проти змінного?" питання. Я впевнений, що у випадку Джанго є набагато більше міркувань щодо дизайну, ніж вище.

Мені подобається, що вона за замовчуванням незмінна. Як зазначалося, ви можете зробити його зміненим, якщо вам потрібно, але ви повинні бути чітко про це. Це як "я знаю, що можу зробити свою форму налагодженням кошмаром, але я знаю, що зараз роблю".

Я знайшов це в коментарі до відповіді на стек 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

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