django: ¿por qué el objeto request.POST es inmutable?

Como pregunta el título, ¿por qué los chicos de Django decidieron implementar el objeto request.POST con un querydict (que, por supuesto, a su vez, hace que todo sea inmutable?)

Sé que puedes mutilarlo haciendo una copia de los datos de la publicación.

post = request.POST.copy()

pero ¿por qué hacer esto? Seguramente sería más simple permitir que la cosa fuera mutable de todos modos. ¿O también se está utilizando por alguna otra razón que podría causar problemas?

Es un poco misterioso, ¿no? Varias teorías superficialmente plausibles resultan estar equivocadas en la investigación:

1. ¿Para que el POSTobjeto no tenga que implementar métodos de mutación? No: la POSTpropiedad pertenece a la django.http.QueryDictclase , que implementa un conjunto completo de procedimientos de mutación incluyendo __setitem__, __delitem__, popy clear. Implementa la inmutabilidad marcando una bandera cuando llamas a uno de los métodos de mutación. Y cuando llamas al copymétodo, obtienes otra QueryDictinstancia con la bandera mutable activada.

2. ¿Para mejorar el rendimiento? No: la QueryDictclase no obtiene ningún beneficio de rendimiento cuando la bandera mutable está desactivada.

3. ¿Para que el POSTobjeto se pueda utilizar como clave de diccionario? No: los QueryDictobjetos no se pueden mezclar con hash.

4. ¿Para que los POSTdatos se puedan construir de forma perezosa (sin comprometerse a leer la respuesta completa), como se afirma aquí ? No veo evidencia de esto en el código: por lo que puedo decir, la totalidad de la respuesta siempre se lee, ya sea directamente o a través MultiPartParserde las multipartrespuestas.

5. ¿Para protegerte contra errores de programación? He visto este reclamo, pero nunca he visto una buena explicación de qué son estos errores y cómo la inmutabilidad te protege contra ellos.

En cualquier caso, POSTes no siempre inmutable : cuando la respuesta es multipart, entonces POSTes mutable. Esto parece poner freno a la mayoría de las teorías que se te ocurran. (A menos que este comportamiento sea un descuido).

En resumen, no veo una justificación clara en Django para que el POSTobjeto sea inmutable para las no multipartsolicitudes.

Si la solicitud fue el resultado de un formenvío de Django , entonces es razonable que POST immutablegarantice la integridad de los datos entre el envío del formulario y la validación del formulario . Sin embargo, si la solicitud no se envió a través de un formenvío de Django , entonces POST es mutableporque no hay validación del formulario.

Siempre puedes hacer algo como esto: (según el comentario de @ leo-the-manic )

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

Actualización :

Gareth Rees tenía razón en que los puntos 1 y 3 no eran válidos en este caso. Aunque creo que los puntos 2 y 4 siguen siendo válidos, dejaré las tesis aquí.

(Me di cuenta de que el request.POSTobjeto tanto de Pyramid (Pylon) como de Django es una forma de MultiDict. Así que quizás sea una práctica más común que hacer request.POSTinmutable).

No puedo hablar por los chicos de Django, aunque me parece que podría hacerlo por algunas de estas razones:

1. Rendimiento . Los objetos inmutables son "más rápidos" que los mutables en el sentido de que permiten optimizaciones sustanciales. Un objeto es inmutable significa que podemos asignarle espacio en el momento de la creación y los requisitos de espacio no cambian. También tiene cosas como eficiencia de copia y eficiencia de comparación debido a eso. Editar : este no es el casoQueryDictcomo señaló Gareth Rees.
2. En el caso de request.POST, parece que ninguna actividad en el lado del servidor debería necesitar alterar los datos de la solicitud . Y, por lo tanto, los objetos inmutables son más adecuados, sin mencionar que tienen una ventaja de rendimiento sustancial.
3. Los objetos inmutables se pueden usar como dictclaves, lo que supongo que podría ser muy útil en algún lugar de Django .. Editar : mi error, inmutable no implica directamente hash ; Sin embargo, los objetos hash , normalmente también son inmutables .
4. Cuando pase request.POST(especialmente a complementos de terceros y hacia fuera), puede esperar que este objeto de solicitud del usuario permanezca sin cambios.

De alguna manera, estas razones también son respuestas genéricas a "inmutable vs mutable?" pregunta. Estoy seguro de que hay muchas más consideraciones de diseño que las anteriores en el caso de Django.

Me gusta que sea inmutable por defecto. Como se señaló, puede hacerlo mutable si es necesario, pero debe ser explícito al respecto. Es como 'Sé que puedo hacer que la depuración de mi formulario sea una pesadilla, pero sé lo que estoy haciendo ahora'.

Encontré esto en un comentario en Stack Answer https://stackoverflow.com/a/2339963

Y debe ser inmutable para que se pueda construir con pereza. La copia obliga a obtener todos los datos POST. Hasta la copia, es posible que no se recupere todo. Además, para que un servidor WSGI de subprocesos múltiples funcione razonablemente bien, es útil si esto es inmutable

Tenga en cuenta: la multipartsolicitud es inmutable desde Django 1.11 https://github.com/django/django/blob/stable/1.11.x/django/http/multipartparser.py#L292

Eran mutables en versiones anteriores.