django - dlaczego obiekt request.POST jest niezmienny?

Jak pyta tytuł, dlaczego chłopaki z Django zdecydowali się zaimplementować obiekt request.POST za pomocą querydict (co oczywiście sprawia, że ​​całość jest niezmienna?)

Wiem, że możesz to zmienić , wykonując kopię danych postu

post = request.POST.copy()

ale dlaczego to robisz? Z pewnością prościej byłoby po prostu pozwolić, aby i tak było to zmienne? A może jest używany również z innego powodu, który może powodować problem?

To trochę tajemnica, prawda? Kilka powierzchownie wiarygodnych teorii okazuje się błędnych w badaniu:

1. Aby POSTobiekt nie musiał implementować metod mutacji? Nie: POSTprzedmiot należący do django.http.QueryDictklasy , która implementuje pełen zestaw metod mutacji tym __setitem__, __delitem__, popi clear. Implementuje niezmienność, sprawdzając flagę podczas wywoływania jednej z metod mutacji. A kiedy wywołasz copymetodę, otrzymasz kolejną QueryDictinstancję z włączoną flagą mutable.

2. Aby poprawić wydajność? Nie: QueryDictklasa nie zyskuje na wydajności, gdy flaga mutacji jest wyłączona.

3. Aby POSTobiekt mógł służyć jako klucz słownika? Nie: QueryDictobiekty nie podlegają hashowaniu.

4. Aby POSTdane mogły być budowane leniwie (bez zobowiązania się do przeczytania całej odpowiedzi), jak tu twierdzono ? Nie widzę tego dowody w kodzie: o ile mogę powiedzieć, cała odpowiedź jest zawsze czytać, albo bezpośrednio , albo za pośrednictwem MultiPartParserza multipartodpowiedzi.

5. Aby uchronić Cię przed błędami programistycznymi? Widziałem, jak to twierdzono, ale nigdy nie widziałem dobrego wyjaśnienia, czym są te błędy i jak niezmienność chroni cię przed nimi.

W każdym razie, POSTto nie zawsze niezmienne : gdy odpowiedź jest multipart, to POSTjest zmienny. To wydaje się stawiać kibosha na większości teorii, o których możesz pomyśleć. (Chyba że takie zachowanie jest przeoczeniem).

Podsumowując, nie widzę jasnego uzasadnienia w Django, aby POSTobiekt był niezmienny dla nie- multipartżądań.

Jeśli żądanie było wynikiem formprzesłania Django , wówczas POST immutablepowinien zapewnić integralność danych między wysłaniem formularza a walidacją formularza . Jeśli jednak żądanie nie zostało wysłane za pośrednictwem przesłania Django form, POST jest, mutableponieważ nie ma walidacji formularza.

Zawsze możesz zrobić coś takiego: (zgodnie z komentarzem @ leo-the-manic )

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

Aktualizacja :

Gareth Rees miał rację, że punkty 1 i 3 nie były ważne w tym przypadku. Chociaż myślę, że punkty 2 i 4 są nadal aktualne, dlatego tezy zostawię tutaj.

(Zauważyłem, że request.POSTobiekt zarówno Pyramid (Pylon), jak i Django jest jakąś formą MultiDict. Więc być może jest to bardziej powszechna praktyka niż uczynienie request.POSTniezmiennym.)

Nie mogę mówić w imieniu chłopaków z Django, chociaż wydaje mi się, że może to z kilku następujących powodów:

1. Wydajność . Niezmienne obiekty są „szybsze” niż zmienne, ponieważ pozwalają na znaczące optymalizacje. Obiekt jest niezmienny, co oznacza, że ​​możemy przydzielić mu miejsce w czasie tworzenia , a wymagania przestrzenne się nie zmieniają. Z tego powodu ma również takie rzeczy, jak wydajność kopiowania i wydajność porównania. Edycja : tak nie jest,QueryDictjak wskazał Gareth Rees.
2. W przypadku request.POSTwydaje się, że żadna aktywność po stronie serwera nie powinna powodować konieczności zmiany danych żądania . A zatem niezmienne obiekty są bardziej odpowiednie, nie wspominając o tym, że mają znaczną przewagę wydajnościową.
3. Niezmienne obiekty mogą być używane jako dictklucze, które ja przypuszczam może być bardzo przydatna gdzieś w Django .. Edit : moja pomyłka, niezmienne bezpośrednio nie sugerować hashable ; obiekty, które można mieszać , są jednak również zwykle niezmienne .
4. Kiedy mijasz request.POST(szczególnie do wtyczek innych firm i poza nimi), możesz spodziewać się, że obiekt żądania od użytkownika pozostanie niezmieniony.

W pewnym sensie te powody są również ogólnymi odpowiedziami na pytanie „niezmienny czy zmienny?” pytanie. Jestem pewien, że w przypadku Django istnieje znacznie więcej rozważań projektowych niż powyżej.

Podoba mi się, że domyślnie jest niezmienny. Jak wskazano, możesz uczynić go zmiennym, jeśli potrzebujesz, ale musisz to wyraźnie powiedzieć. To coś w stylu „Wiem, że debugowanie formularza może stać się koszmarem, ale wiem, co teraz robię”.

Znalazłem to w komentarzu do odpowiedzi stosu https://stackoverflow.com/a/2339963

I musi być niezmienny, żeby można go było leniwie budować. Kopia wymusza pobranie wszystkich danych POST. Do czasu skopiowania nie wszystko może zostać pobrane. Ponadto, aby wielowątkowy serwer WSGI działał w miarę dobrze, pomocne jest, jeśli jest to niezmienne

Uwaga: multipartżądania są niezmienne od wersji 1.11 Django https://github.com/django/django/blob/stable/1.11.x/django/http/multipartparser.py#L292

W poprzednich wersjach były zmienne.