django - warum ist das request.POST-Objekt unveränderlich?

Wie der Titel fragt, warum haben die Django-Leute beschlossen, die Anfrage zu implementieren. POST-Objekt mit einem Querydict (was natürlich wiederum das Ganze unveränderlich macht?)

Ich weiß, dass Sie es ändern können, indem Sie eine Kopie der Postdaten erstellen

post = request.POST.copy()

aber warum das? Sicherlich wäre es einfacher, das Ding trotzdem veränderlich zu machen? Oder wird es auch aus einem anderen Grund verwendet, der Probleme verursachen könnte?

Es ist ein bisschen ein Rätsel, nicht wahr? Mehrere oberflächlich plausible Theorien erweisen sich bei der Untersuchung als falsch:

1. Damit das POSTObjekt keine Mutationsmethoden implementieren muss? Nein: Das POSTObjekt gehört zum django.http.QueryDictKlasse , die implementiert ein vollständiger Satz von Mutationsverfahren einschließlich __setitem__, __delitem__, popund clear. Es implementiert Unveränderlichkeit, indem ein Flag überprüft wird, wenn Sie eine der Mutationsmethoden aufrufen. Und wenn Sie die copyMethode aufrufen , erhalten Sie eine andere QueryDictInstanz mit aktiviertem veränderlichen Flag.

2. Zur Leistungsverbesserung? Nein: Die QueryDictKlasse erhält keinen Leistungsvorteil, wenn das veränderbare Flag deaktiviert ist.

3. Damit das POSTObjekt als Wörterbuchschlüssel verwendet werden kann? Nein: QueryDictObjekte sind nicht hashbar.

4. Damit die POSTDaten träge erstellt werden können (ohne die gesamte Antwort zu lesen), wie hier behauptet ? Ich sehe keinen Beweis dafür im Code: soweit ich das beurteilen kann, die Gesamtheit der Antwort wird immer gelesen, entweder direkt oder über MultiPartParserfür multipartAntworten.

5. Um Sie vor Programmierfehlern zu schützen? Ich habe dies behauptet gesehen, aber ich habe nie eine gute Erklärung dafür gesehen, was diese Fehler sind und wie Unveränderlichkeit Sie vor ihnen schützt.

In jedem Fall POSTist nicht immer unveränderlich : Wenn die Antwort ist multipart, dann POSTist veränderlich. Dies scheint den Kibosh auf die meisten Theorien zu setzen, an die Sie vielleicht denken. (Es sei denn, dieses Verhalten ist ein Versehen.)

Zusammenfassend kann ich in Django keine klare Begründung dafür sehen, dass das POSTObjekt für Nichtanfragen unveränderlich ist multipart.

Wenn die Anfrage das Ergebnis einer Django- formÜbermittlung war, ist es für POST sinnvoll immutable, die Integrität der Daten zwischen der Übermittlung des Formulars und der Validierung des Formulars sicherzustellen . Wenn die Anfrage jedoch nicht über eine Django- formÜbermittlung gesendet wurde , erfolgt POST, mutableda keine Formularvalidierung erfolgt.

Sie können immer so etwas tun: (gemäß dem Kommentar von @ leo-the-manic )

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

Update :

Gareth Rees hatte Recht, dass die Punkte 1 und 3 in diesem Fall nicht gültig waren. Obwohl ich denke, dass Punkt 2 und 4 noch gültig sind, werde ich diese hier belassen.

(Mir ist aufgefallen, dass das request.POSTObjekt von Pyramid (Pylon) und Django eine Form von ist MultiDict. Vielleicht ist es eine üblichere Praxis, als request.POSTunveränderlich zu machen.)

Ich kann nicht für die Django-Leute sprechen, obwohl es mir aus folgenden Gründen so scheint:

1. Leistung . unveränderliche Objekte sind "schneller" als veränderbare, da sie wesentliche Optimierungen ermöglichen. Ein Objekt ist unveränderlich. Dies bedeutet, dass wir ihm zum Zeitpunkt der Erstellung Speicherplatz zuweisen können und sich der Speicherplatzbedarf nicht ändert. Es hat auch Dinge wie Kopiereffizienz und Vergleichseffizienz aufgrund dessen. Bearbeiten : Dies ist nicht der Fall,QueryDictwie Gareth Rees betonte.
2. Im Fall von request.POSTsollte anscheinend keine Aktivität auf der Serverseite erforderlich sein, um die Daten der Anforderung zu ändern . Und daher sind unveränderliche Objekte besser geeignet, ganz zu schweigen davon, dass sie einen erheblichen Leistungsvorteil haben.
3. Unveränderliche Objekte können als dictSchlüssel verwendet werden, was vermutlich irgendwo in Django sehr nützlich sein könnte. Bearbeiten : Mein Fehler, unveränderlich bedeutet nicht direkt Hashable ; Hash- Objekte sind jedoch normalerweise auch unveränderlich .
4. Wenn Sie weitergeben request.POST(insbesondere an Plugins von Drittanbietern und Outs), können Sie davon ausgehen, dass dieses Anforderungsobjekt des Benutzers unverändert bleibt.

In gewisser Weise sind diese Gründe auch generische Antworten auf "unveränderlich gegen veränderlich?" Frage. Ich bin sicher, dass es im Fall Django viel mehr Überlegungen zum Design gibt als oben.

Ich mag es, wenn es standardmäßig unveränderlich ist. Wie bereits erwähnt, können Sie es bei Bedarf veränderbar machen, müssen dies jedoch explizit angeben. Es ist wie "Ich weiß, dass ich mein Formular zum Debuggen zu einem Albtraum machen kann, aber ich weiß, was ich jetzt tue."

Ich habe dies in einem Kommentar zu Stack Answer https://stackoverflow.com/a/2339963 gefunden

Und es muss unveränderlich sein, damit es träge gebaut werden kann. Die Kopie erzwingt das Abrufen aller POST-Daten. Bis zur Kopie wird möglicherweise nicht alles abgerufen. Damit ein Multithread-WSGI-Server einigermaßen gut funktioniert, ist es hilfreich, wenn dies unveränderlich ist

Bitte beachten Sie: multipartAnfragen sind seit Django 1.11 https://github.com/django/django/blob/stable/1.11.x/django/http/multipartparser.py#L292 unveränderlich

Sie waren in früheren Versionen veränderlich.