django - por que o objeto request.POST é imutável?

Como o título pergunta, por que os caras do Django decidiram implementar o objeto request.POST com um querydict (que, é claro, por sua vez, torna tudo imutável?)

Eu sei que você pode modificá- lo fazendo uma cópia dos dados da postagem

post = request.POST.copy()

mas por que fazer isso? Certamente seria mais simples permitir que a coisa fosse mutável de qualquer maneira? Ou está sendo usado por algum outro motivo que pode causar problemas?

É um pouco misterioso, não é? Várias teorias superficialmente plausíveis revelaram-se erradas na investigação:

1. Para que o POSTobjeto não precise implementar métodos de mutação? Não: o POSTobjeto pertence à django.http.QueryDictclasse , que implementa um conjunto completo de métodos de mutação, incluindo __setitem__, __delitem__, pope clear. Ele implementa a imutabilidade verificando um sinalizador quando você chama um dos métodos de mutação. E quando você liga para ocopy método, você obtém outra QueryDictinstância com o sinalizador mutável ativado.

2. Para melhoria de desempenho? Não: oQueryDict classe não ganha nenhum benefício de desempenho quando o sinalizador mutável é desativado.

3. Para que o POST objeto possa ser usado como chave de dicionário? Não: os QueryDictobjetos não são hashable.

4. Para que os POSTdados possam ser construídos preguiçosamente (sem se comprometer a ler toda a resposta), como afirmado aqui ? Não vejo evidência disso no código: pelo que posso dizer, toda a resposta é sempre lida, diretamente ou por meio MultiPartParserde multipartrespostas.

5. Para protegê-lo contra erros de programação? Já vi isso ser reivindicado, mas nunca vi uma boa explicação sobre o que são esses erros e como a imutabilidade o protege contra eles.

Em qualquer caso, POSTé não sempre imutável : quando a resposta é multipart, em seguida, POSTé mutável. Isso parece acabar com a maioria das teorias que você possa imaginar. (A menos que esse comportamento seja um descuido.)

Em resumo, não consigo ver nenhuma justificativa clara no Django para o POSTobjeto ser imutável para não- multipartrequisições.

Se a solicitação foi o resultado de um formenvio do Django , então é razoável para o POST immutablegarantir a integridade dos dados entre o envio do formulário e a validação do formulário . No entanto, se a solicitação não foi enviada por meio de um formenvio do Django , o POST émutable pois não há validação do formulário.

Você sempre pode fazer algo assim: (de acordo com o comentário de @leo-the-manic )

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

Atualização :

Gareth Rees estava certo ao dizer que os pontos 1 e 3 não eram válidos neste caso. Embora eu ache que os pontos 2 e 4 ainda sejam válidos, deixarei as teses aqui.

(Percebi que o request.POSTobjeto de ambos Pyramid (Pylon) e Django é alguma forma de MultiDict. Portanto, talvez seja uma prática mais comum do que tornar request.POSTimutável.)

Não posso falar pelos caras do Django, embora me pareça que poderia por alguns destes motivos:

1. Performance . objetos imutáveis ​​são "mais rápidos" do que os mutáveis, pois permitem otimizações substanciais. Um objeto é imutável significa que podemos alocar espaço para ele no momento da criação e os requisitos de espaço não estão mudando. Ele também tem coisas como eficiência de cópia e eficiência de comparação por causa disso. Edit : este não é o caso deQueryDictcomo Gareth Rees apontou.
2. No caso de request.POST, parece que nenhuma atividade no lado do servidor deve precisar alterar os dados da solicitação . E, portanto, os objetos imutáveis ​​são mais adequados, sem mencionar que têm uma vantagem substancial de desempenho.
3. Objetos imutáveis ​​podem ser usados ​​como dictchaves, o que eu suponho que podem ser muito úteis em algum lugar do Django .. Edit : meu erro, imutável não implica diretamente em hash ; objetos hashable , entretanto, são tipicamente imutáveis também.
4. Ao passar request.POST(especialmente para plug-ins de terceiros e outros), você pode esperar que esse objeto de solicitação do usuário permaneça inalterado.

De alguma forma, essas razões também são respostas genéricas para "imutável versus mutável?" questão. Estou certo de que há muito mais considerações de design do que acima no caso do Django.

Eu gosto de ser imutável por padrão. Como apontado, você pode torná-lo mutável se precisar, mas deve ser explícito sobre isso. É como 'Eu sei que posso tornar a depuração de meu formulário um pesadelo, mas sei o que estou fazendo agora.'

Eu encontrei isso em um comentário na Stack Answer https://stackoverflow.com/a/2339963

E deve ser imutável para que possa ser construído preguiçosamente. A cópia força a obtenção de todos os dados POST. Até a cópia, nem tudo pode ser obtido. Além disso, para um servidor WSGI multi-threaded funcionar razoavelmente bem, é útil se isso for imutável

Observação: as multipartsolicitações são imutáveis ​​desde Django 1.11 https://github.com/django/django/blob/stable/1.11.x/django/http/multipartparser.py#L292

Eles eram mutáveis ​​nas versões anteriores.