django - perché l'oggetto request.POST è immutabile?

Come chiede il titolo, perché i ragazzi di Django hanno deciso di implementare l'oggetto request.POST con un querydict (che, ovviamente, a sua volta, rende il tutto immutabile?)

So che puoi modificarlo facendo una copia dei dati del post

post = request.POST.copy()

ma perché farlo? Sicuramente sarebbe più semplice lasciare che la cosa sia comunque mutevole? O viene utilizzato anche per qualche altro motivo che potrebbe causare problemi?

È un po 'un mistero, non è vero? Diverse teorie superficialmente plausibili si rivelano errate durante le indagini:

1. In modo che l' POSToggetto non debba implementare metodi di mutazione? No: l' POSToggetto appartiene alla django.http.QueryDictclasse , che implementa una serie completa di metodi di mutazione tra cui __setitem__, __delitem__, pope clear. Implementa l'immutabilità controllando un flag quando si chiama uno dei metodi di mutazione. E quando chiami il copymetodo ottieni un'altra QueryDictistanza con il flag mutabile attivato.

2. Per migliorare le prestazioni? No: la QueryDictclasse non ottiene alcun vantaggio in termini di prestazioni quando il flag mutabile è disattivato.

3. In modo che l' POSToggetto possa essere utilizzato come chiave del dizionario? No: gli QueryDictoggetti non sono modificabili.

4. In modo che i POSTdati possano essere costruiti pigramente (senza impegnarsi a leggere l'intera risposta), come affermato qui ? Non vedo alcuna prova di ciò nel codice: per quanto ne so, l'intera risposta viene sempre letta, direttamente o tramite MultiPartParserper le multipartrisposte.

5. Per proteggerti dagli errori di programmazione? Ho visto questo affermato, ma non ho mai visto una buona spiegazione di cosa siano questi errori e di come l'immutabilità ti protegga da essi.

In ogni caso, nonPOST è sempre immutabile : quando la risposta c'è multipart, allora POSTè mutabile. Questo sembra mettere il kibosh sulla maggior parte delle teorie a cui potresti pensare. (A meno che questo comportamento non sia una svista.)

In sintesi, non vedo una chiara motivazione in Django per cui l' POSToggetto sia immutabile per le non multipartrichieste.

Se la richiesta è il risultato di un forminvio Django , è ragionevole che POST immutablegarantisca l'integrità dei dati tra l' invio del modulo e la convalida del modulo . Tuttavia, se la richiesta non è stata inviata tramite una formpresentazione Django , allora il POST è mutableperché non c'è convalida del modulo.

Puoi sempre fare qualcosa del genere: (come da commento di @ leo-the-mania )

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

Aggiornamento :

Gareth Rees aveva ragione sul fatto che i punti 1 e 3 non erano validi in questo caso. Anche se penso che i punti 2 e 4 siano ancora validi, quindi lascerò qui le tesi.

(Ho notato che l' request.POSToggetto di Pyramid (Pylon) e Django è una qualche forma di MultiDict. Quindi forse è una pratica più comune che rendere request.POSTimmutabile.)

Non posso parlare per i ragazzi di Django, anche se mi sembra che potrebbe a causa di alcuni di questi motivi:

1. Performance . gli oggetti immutabili sono "più veloci" rispetto a quelli mutabili in quanto consentono sostanziali ottimizzazioni. Un oggetto è immutabile significa che possiamo allocare spazio per esso al momento della creazione e i requisiti di spazio non cambiano. Per questo ha anche cose come l'efficienza della copia e l'efficienza del confronto. Modifica : questo non è il caso diQueryDictcome ha sottolineato Gareth Rees.
2. Nel caso di request.POST, sembra che nessuna attività sul lato server debba modificare i dati della richiesta . E quindi gli oggetti immutabili sono più adatti, per non parlare del fatto che hanno un vantaggio sostanziale in termini di prestazioni.
3. Gli oggetti immutabili possono essere usati come dictchiavi, che suppongo potrebbero essere molto utili da qualche parte in Django .. Modifica : il mio errore, immutabile non implica direttamente hashable ; gli oggetti hashable tuttavia, sono tipicamente immutabili pure.
4. Quando si passa in giro request.POST(specialmente a plug-in di terze parti e fuori), ci si può aspettare che questo oggetto di richiesta dell'utente rimanga invariato.

In qualche modo queste ragioni sono anche risposte generiche a "immutabile vs mutabile?" domanda. Sono certo che nel caso Django ci siano molte più considerazioni sul design rispetto a sopra.

Mi piace che sia immutabile per impostazione predefinita. Come accennato, puoi renderlo mutabile se necessario, ma devi essere esplicito al riguardo. È come "So che posso rendere il mio modulo debugging un incubo, ma so cosa sto facendo ora".

L'ho trovato in un commento su Stack Answer https://stackoverflow.com/a/2339963

E deve essere immutabile in modo che possa essere costruito pigramente. La copia forza l'acquisizione di tutti i dati POST. Fino alla copia, potrebbe non essere tutto recuperato. Inoltre, affinché un server WSGI multi-thread funzioni ragionevolmente bene, è utile se non è modificabile

Nota: le multipartrichieste non sono modificabili da Django 1.11 https://github.com/django/django/blob/stable/1.11.x/django/http/multipartparser.py#L292

Erano mutabili nelle versioni precedenti.