Novidades do Django 6.0

• Django 6.0, que celebra 20 anos, é uma grande versão com melhorias significativas em áreas centrais como templates, tarefas em segundo plano, segurança e e-mail
• O recurso Template partials facilita a reutilização de código dentro dos templates e fortalece a integração com ferramentas como o htmx
• O novo framework de Tasks foi adicionado para executar tarefas em segundo plano fora do ciclo de requisição-resposta HTTP
• Content Security Policy (CSP) agora vem integrada por padrão, facilitando a defesa contra ataques de injeção de conteúdo como XSS
• Modernização da API de e-mail, melhorias no ORM e expansão das chaves primárias aumentam bastante a experiência do desenvolvedor e a escalabilidade

---

Visão geral do Django 6.0

• Django 6.0 é uma nova versão do framework web em Python, dando continuidade a 20 anos de evolução
• As principais mudanças se concentram em quatro áreas centrais: templates, tarefas em segundo plano, segurança e processamento de e-mail
• Vários contribuidores da comunidade de desenvolvedores participaram, e os principais avanços foram organizados com base nas notas oficiais de lançamento

Ferramenta django-upgrade

• Ao atualizar projetos existentes do Django 5.2 ou inferior, a ferramenta django-upgrade pode fazer transformações automáticas no código
• Ela inclui 5 fixers automáticos relacionados ao Django 6.0 e resolve alguns avisos automaticamente

Template partials

• Foi adicionado o recurso de definição de partes de template ({% partialdef %}), permitindo reduzir duplicação e reutilizar código dentro dos templates
  • É possível chamar várias vezes uma partial definida no mesmo template
  • Com a opção inline, é possível definir e renderizar ao mesmo tempo
• O recurso de renderização parcial permite renderizar apenas uma partial específica de forma independente
  • No exemplo, o htmx é usado para atualizar periodicamente a parte view_count
  • Ao adicionar #partial_name à URL, é possível renderizar apenas aquela parte específica
• Esse recurso foi integrado ao Django por meio de um projeto do Google Summer of Code e evoluiu a partir do pacote django-template-partials

Framework de Tasks

• O Django agora inclui um novo framework de Tasks para execução de trabalhos em segundo plano
  • Permite executar código fora do ciclo de requisição-resposta HTTP
  • Pode ser usado para tarefas assíncronas como envio de e-mails, processamento de dados e geração de relatórios
• As tarefas são definidas com o decorator @task e podem ser enfileiradas com Task.enqueue()
• Os backends fornecidos por padrão são ImmediateBackend e DummyBackend, ambos voltados para desenvolvimento, e
  com o DatabaseBackend do pacote django-tasks é possível executar com base em banco SQL
• O worker de tarefas é executado com o comando db_worker, e o status pode ser acompanhado pelos logs
• Esse recurso nasceu de uma ideia iniciada no Wagtail e foi integrado ao Django após a proposta DEP 0014

Suporte a Content Security Policy (CSP)

• O Django 6.0 oferece suporte nativo ao padrão CSP, reforçando a proteção contra ataques de injeção de conteúdo como XSS
  • Ative adicionando ContentSecurityPolicyMiddleware em MIDDLEWARE
  • A política pode ser configurada com SECURE_CSP e SECURE_CSP_REPORT_ONLY
• A segurança baseada em nonce vem embutida, permitindo adicionar o atributo nonce="{{ csp_nonce }}" às tags <script> e <style>
  • Um nonce aleatório é gerado a cada requisição, permitindo a execução apenas de recursos confiáveis
• O CSP vinha sendo implementado pelo pacote django-csp desde sua proposta em 2004, e agora passa a fazer parte oficial do framework

Atualização da API de e-mail

• A lógica de processamento de e-mail do Django foi migrada para a API moderna de e-mail do Python 3.6
  • Internamente, passa a usar a classe email.message.EmailMessage
  • As interfaces existentes send_mail() e EmailMessage continuam as mesmas
• A nova API oferece vantagens como menos bugs, mais segurança e melhor tratamento de anexos inline
• Com objetos MIMEPart, é possível adicionar com facilidade anexos inline como imagens em corpo HTML
• Essa mudança foi proposta em 2024 e incorporada após 8 meses de desenvolvimento

Restrição de argumentos posicionais na API de e-mail

• Na API django.core.mail, alguns parâmetros passaram a aceitar apenas argumentos nomeados
  • Ao passar argumentos opcionais como fail_silently por posição, um aviso é emitido
  • A mudança busca melhorar legibilidade e manutenção
• É possível corrigir automaticamente com o fixer mail_api_kwargs do django-upgrade

Expansão do auto import no Shell

• O recurso de importação automática de modelos do Django 5.2 foi ampliado,
  incluindo settings, connection, models, functions, timezone automaticamente
• É possível verificar a lista de imports automáticos com ./manage.py shell -v 2
• Isso melhora a conveniência no desenvolvimento e reduz código repetitivo

Melhorias no ORM: atualização dinâmica de campos no save()

• GeneratedField e campos baseados em expressões passam a ser atualizados automaticamente após save()
  • Em bancos com suporte à cláusula RETURNING (SQLite, PostgreSQL, Oracle), a atualização é refletida imediatamente
  • No MySQL e MariaDB, a atualização automática acontece por carregamento tardio
• Isso melhora a eficiência ao permitir usar imediatamente os valores mais recentes sem consultas adicionais

Função de agregação universal StringAgg

• A função de agregação StringAgg agora pode ser usada em todos os backends de banco de dados
  • Ela retorna uma string com os valores de entrada unidos por um delimitador
  • Antes era um recurso exclusivo do PostgreSQL, mas agora pode ser usada diretamente em django.db.models
• O delimitador pode ser especificado com a expressão Value()

BigAutoField como padrão

• O valor padrão de DEFAULT_AUTO_FIELD foi alterado para BigAutoField
  • Isso usa chaves primárias inteiras de 64 bits, ajudando a prevenir o esgotamento de Primary Keys
  • Em novos projetos, isso se aplica automaticamente sem configuração extra
• A mudança simplifica a configuração introduzida no Django 3.2 e reduz boilerplate

Melhorias em templates

• A variável forloop.length foi adicionada, permitindo consultar o tamanho total dentro do loop
  • Pode ser usada no formato {{ forloop.counter }}/{{ forloop.length }}
• Melhorias na tag de template querystring
  • Agora ? é adicionado automaticamente em mapeamentos vazios, garantindo consistência no comportamento dos links
  • Também há suporte à mesclagem de múltiplos argumentos de mapeamento, facilitando a composição de parâmetros de query

Encerrando

• O Django 6.0 contou com a participação de 174 contribuidores e
  inclui numerosas otimizações e correções de bugs
• Com a atualização, segurança, manutenção e experiência do desenvolvedor (DX) melhoram de forma geral
• Mais mudanças podem ser consultadas nas notas oficiais de lançamento

[GN⁺]

Comentários do Hacker News

• Há alguns anos venho usando Django de forma intermitente no trabalho. No geral gosto, mas o ORM ainda parece difícil.
  Só agora entendi que Django é um framework com opiniões fortes e que é preciso seguir o “jeito Django”.
  O problema é que preciso lidar com múltiplos bancos de dados de várias áreas de negócio, então sofro para acomodar essas particularidades toda vez.
  No fim, acabo desativando managed, importando o esquema com inspectdb e depois removendo manualmente as tabelas que não quero expor na web.
  Para novas aplicações web, Django ainda é a melhor escolha

  • Concordo. Mas o fluxo de trabalho de migrações de banco ainda deixa a desejar.
    O Django não armazena o estado do esquema junto com o código, então toda vez que executa um comando no banco ele precisa inferir o estado atual.
    Definir o estado do banco pelo código dos models tem limitações inerentes.
    Eu prefiro bem mais a abordagem do Rails, de montar as migrações com comandos explícitos de banco e colocar os models por cima disso
  • Fico curioso se você está usando o suporte a múltiplos bancos de dados do Django
  • Usei Aldjemy num projeto pequeno, e ele lidou bem com combinações de consultas complexas que são difíceis no ORM do Django
  • Uso Django há mais de 10 anos e o ORM é “ok”. Houve um tempo em que existia um movimento para trocar por SQLAlchemy, mas não valia a pena.
    A interface de Manager confunde no começo, mas a ferramenta de migrações é realmente excelente
  • Configurar views ou materialized views via ORM ajuda muito no desempenho.
    Dá para ter ao mesmo tempo a flexibilidade de ajuste fino em SQL e a conveniência do Django.
    Só não pode esquecer de criá-las dentro dos scripts de migração

• Gosto muito de como o Django vai melhorando de forma constante a cada release.
  A versão 6.0, em especial, parece interessante porque traz muitos recursos úteis.
  Está errado quem diz que tecnologia confiável é chata. É assim mesmo que ela deve evoluir

  • Também uso desde a época pré-1.0 e continuo gostando.
    Hoje moro perto do local de nascimento do Django.
    E, além disso, comecei a procurar emprego ontem, então se alguém estiver buscando um desenvolvedor Django experiente, entre em contato ([e-mail])

• Código ou blog escrito pelo Adam sempre vale a leitura.
  Estou curioso para ver como o framework de tasks vai evoluir daqui para frente.
  Só achei um pouco triste o ótimo Django-Q2 ter sido mencionado junto com Celery

  • Sou o autor. Obrigado pelo elogio, e o Celery foi citado apenas por popularidade ;)
  • Celery não é perfeito, mas é a melhor opção.
    Tem muitos bugs, mas a base de usuários é tão grande que raramente você é o primeiro a encontrar um problema.
    Já usei a combinação Celery + RabbitMQ para processar com estabilidade dezenas de milhões de mensagens por dia.
    Ainda é uma solução que vale considerar primeiro
  • Uso Celery há anos e fiquei curioso sobre o que exatamente era o problema e como o Django Q2 melhora isso.
    Em outras stacks também usamos Kafka, mas isso já é um caso de uso de outro nível
  • Fico curioso por que dizem que o Celery é “terrível”

• Uso Django há uns 5 ou 6 anos e, embora a vantagem de “batteries included” seja clara, no geral ele parece pesado

• O recurso de template partial parece muito bom.
  Um dos motivos de React ter ficado popular foi a reutilização de código, e parece que o Django está indo nessa direção

  • O ponto central da reutilização e da composabilidade no React não é template, e sim o fato de que tudo é função
  • Esse recurso tem bastante valor especialmente quando usado com HTMX. HTMX precisa de muitos templates parciais
  • React não oferece apenas templates simples, e sim componentes que encapsulam estado
  • Também testei o Django 6 e usei partials no meu blog.
    O exemplo está neste código
  • Surpreende que o Django só tenha adicionado esse recurso em 2025

• Eu uso principalmente Odoo, mas também já mexi um pouco com Django e Celery.
  Como alguém que usa bastante o módulo de fila da OCA,
  sempre me perguntei por que o Django não aproveita o recurso LISTEN/NOTIFY do Postgres.
  Talvez seja só porque não conheço tão bem o ecossistema do Django

• Template Partials e HTMX parecem a versão do Django de Rails View Components + Stimulus.
  Também é bom ver o recurso de Tasks com suporte oficial

  • Dá para ver a renderização de partials no Rails no guia oficial
  • Fico curioso se, para usar Tasks em produção, também é preciso usar django-tasks

• Uso Django desde a época do 1.x, antes de existirem tasks no framework.
  É realmente surpreendente que só agora tenham adicionado uma funcionalidade de execução de tasks.
  Não é uma crítica, só uma evolução interessante

  • Na verdade, isso é até refrescante. O Django não corre para lançar recursos; ele os implementa direito.
    Cada recurso só entra depois de estar bem validado, e o foco está em LTS e estabilidade de API.
    Por isso, quando sai uma nova versão, quase nunca é preciso reescrever a aplicação inteira
  • Na verdade, o Django já incluía ORM desde a versão 0.95.
    Na época ele era simples, mas durante bastante tempo não havia necessidade de usar raw SQL

• A discussão adicional continua nesta thread

• Uso Django com HTMX e achava templates em nível de componente tão inconvenientes que acabei criando minha própria biblioteca de componentes em Python, Compone.
  Ela pode ser usada não só no Django, mas em qualquer framework web em Python, e oferece uma experiência de desenvolvimento muito mais agradável