Lançamento do Django 6

 (docs.djangoproject.com)
6 pontos por GN⁺ 2025-12-05 | 1 comentários | Compartilhar no WhatsApp
  • A versão 6.0 do framework web Django foi lançada com suporte a Python 3.12 ou superior, e trouxe reforços significativos de segurança, templates e recursos assíncronos
  • O Content Security Policy (CSP) agora é incorporado por padrão para configurar políticas de defesa contra ataques de injeção de conteúdo, como XSS
  • O recurso Template Partials melhora a modularização do código ao permitir definir partes reutilizáveis dentro de templates
  • O framework de Background Tasks foi adicionado para suportar a execução de tarefas assíncronas fora do ciclo de requisição-resposta
  • A adoção da API de e-mail mais moderna do Python, o fim do suporte ao MariaDB 10.5 e a alteração do valor padrão de DEFAULT_AUTO_FIELD representam ajustes de compatibilidade e modernização

Compatibilidade com Python

  • O Django 6.0 oferece suporte a Python 3.12, 3.13 e 3.14, e somente as versões mais recentes de cada série contam com suporte oficial
  • O Django 5.2.x é a última versão com suporte a Python 3.10 e 3.11
  • Após o Django 6.0, é recomendável que aplicativos de terceiros deixem de dar suporte a versões anteriores ao Django 5.2

Principais novidades

Suporte ao Content Security Policy (CSP)

  • O Django passou a incluir nativamente o padrão CSP, fortalecendo a proteção contra ataques de injeção de conteúdo, como XSS
    • É possível definir políticas por meio de ContentSecurityPolicyMiddleware, do processador de contexto csp() e da configuração SECURE_CSP
    • Configuração baseada em dicionário Python para compor políticas de forma clara e segura
  • O modo de monitoramento pode ser ativado com SECURE_CSP_REPORT_ONLY
  • Decorador para sobrescrever ou desativar a política por view disponível

Template Partials

  • Adição das tags partialdef e partial para definir e reutilizar fragmentos de template
  • A sintaxe template_name#partial_name permite referência direta em get_template(), render(), {% include %} e similares
  • Incluído guia de migração para usuários do pacote de terceiros django-template-partials

Framework de Background Tasks

  • Adição ao Django de um framework embutido para execução de tarefas assíncronas
    • Permite enviar e-mails, processar dados etc. fora do ciclo de requisição-resposta HTTP
    • Definição de tarefas com o decorador @task e enfileiramento via enqueue()
  • O backend é definido com a configuração TASKS, e inclui dois backends padrão para desenvolvimento e testes
  • O Django se responsabiliza pela criação e enfileiramento das tarefas, enquanto a execução é feita por processos worker externos

Adoção da API moderna de e-mail do Python

  • A lógica de e-mail do Django migrou para a API moderna do Python a partir do 3.6 (email.message.EmailMessage)
  • As classes SafeMIMEText e SafeMIMEMultipart deixaram de ser utilizadas
  • O tipo de retorno de EmailMessage.message() foi alterado para uma instância de EmailMessage do Python

Melhorias detalhadas

Admin

  • Aplicado o conjunto de ícones Font Awesome Free 6.7.2
  • Personalização do formulário de alteração de senha do admin via propriedade AdminSite.password_change_form
  • Aplicação de ícones e estilos CSS distintos para messages.DEBUG e messages.INFO

Auth

  • O número de iterações de hash do PBKDF2 aumentou de 1.000.000 para 1.200.000

GIS

  • É possível verificar a presença da dimensão M com o atributo GEOSGeometry.hasm
  • Suporte a rotação por ângulo usando a função Rotate
  • O atributo BaseGeometryWidget.base_layer permite customizar o provedor de tiles do mapa
  • Recursos como coveredby, isvalid, GeoHash e IsValid passaram a ser suportados no MariaDB 12.0.1+
  • JavaScript inline removido na renderização de widgets; ao personalizar, pode ser necessário ajustar o template

PostgreSQL

  • Adicionada a expressão Lexeme para reforçar o controle de pesquisa textual completa
  • Parâmetro hints adicionado a operações relacionadas a extensões como CreateExtension
  • Adicionadas verificações de sistema para campos, índices e constraints relacionados ao django.contrib.postgres

Staticfiles

  • ManifestStaticFilesStorage agora garante consistência de ordenação de caminhos, reduzindo diffs desnecessários
  • O comando collectstatic passa a exibir apenas um resumo por padrão; detalhes aparecem com --verbosity 2 ou superior

Outros

  • Adicionado suporte ao idioma Haitian Creole
  • Os comandos startproject e startapp passam a criar automaticamente diretórios inexistentes
  • O comando shell importa automaticamente utilitários padrão, como django.conf.settings
  • Suporte à serialização de zoneinfo.ZoneInfo em migrações
  • Novas funções de agregação adicionadas, como StringAgg e AnyValue
  • Suporte a paginação assíncrona com AsyncPaginator e AsyncPage
  • Suporte a múltiplos cabeçalhos de cookie em ambiente HTTP/2 no ASGI
  • Adição da variável forloop.length no template e melhora no tag querystring
  • DiscoverRunner suporta testes paralelos usando o modo forkserver

Mudanças sem compatibilidade

API de backend de banco de dados

  • BaseDatabaseSchemaEditor e o backend PostgreSQL descontinuaram o uso de CASCADE na remoção de colunas
  • Mudança de nomes de método, como de return_insert_columns() para returning_columns()
  • Quando houver suporte a UPDATE … RETURNING, é possível definir DatabaseFeatures.can_return_rows_from_update=True

Deprecations

  • Fim do suporte ao MariaDB 10.5 (requer 10.6 ou superior)
  • Fim do suporte para Python abaixo de 3.12
    • Versões mínimas principais: aiosmtpd 1.4.5, bcrypt 4.1.1, Pillow 10.1.0, psycopg 3.1.12, entre outras

Email

  • Removidos os atributos mixed_subtype, alternative_subtype e encoding
  • Alterações internas exigem validação de subclasses customizadas de EmailMessage

Alteração do valor padrão de DEFAULT_AUTO_FIELD

  • O padrão mudou de AutoField para BigAutoField
  • Projetos que ignoraram o aviso do Django 3.2 (models.W042) precisam adicionar uma configuração

Expressões ORM

  • O parâmetro de retorno do método as_sql() deve ser uma tupla

Outros

  • Sempre adicionar newline na serialização JSON
  • Versão mínima do asgiref foi aumentada para 3.9.1

Recursos planejados para descontinuação

API django.core.mail

  • Em get_connection(), send_mail() e similares, argumentos opcionais devem ser passados apenas por nome de parâmetro
  • Ao instanciar EmailMessage e EmailMultiAlternatives, apenas os quatro primeiros argumentos podem ser posicionais; os demais devem ser nomeados

Outros

  • Removido BaseDatabaseCreation.create_test_db(serialize), usar serialize_db_to_string()
  • Descontinuados StringAgg e OrderableAggMixin exclusivos do PostgreSQL
  • O protocolo padrão de urlize e urlizetrunc mudará para HTTPS no Django 7.0
  • As configurações ADMINS e MANAGERS devem ser informadas como lista de strings de e-mail, e não mais tuplas (nome, endereço)
  • Descontinuadas classes relacionadas a e-mail, como SafeMIMEText, SafeMIMEMultipart e BadHeaderError

Funções removidas

  • Removido o suporte a argumentos posicionais em BaseConstraint
  • Removidos DjangoDivFormRenderer e Jinja2DivFormRenderer
  • Removido o suporte ao driver de banco de dados cx_Oracle
  • O esquema padrão de forms.URLField foi alterado de "http" para "https"
  • Removido o suporte a argumentos posicionais em Model.save() e Model.asave()
  • Removidos ModelAdmin.log_deletion() e LogEntryManager.log_action()
  • Removido o módulo django.utils.itercompat
  • Removidos os métodos GeoIP2.coords() e GeoIP2.open()
  • Removidos ForeignObject.get_joining_columns() e métodos relacionados

O Django 6.0 aumentou a robustez e a escalabilidade do framework com melhorias de segurança, tarefas assíncronas e adoção de uma API moderna de e-mail, além de consolidar a migração para ambientes com Python 3.12+.

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-05
Opinião no Hacker News

  • Em uma organização onde trabalhei no passado, havia uma codebase “moderna” em NodeJS+React e um app legado em Django baseado em Python 2.7 com quase 15 anos
    No começo, achei que o código antigo seria doloroso de manter, mas aconteceu justamente o contrário
    O app em Django era um prazer de mexer, e o processo de organizá-lo era realmente divertido. Vou até sentir falta quando ele for substituído por uma nova reescrita em Go/React

    • Não entendo por que querem substituir. Se não está quebrado, não há motivo para trocar

  • Parabéns à equipe do Django
    Há muito tempo mantenho um app inicial com Django + Celery + Postgres + Redis + esbuild + Tailwind baseado em Docker Compose e recentemente o atualizei para o Django 6.0
    Dá para ver no repositório no GitHub
    Ainda não incluí a configuração de CSP por padrão, mas pretendo adicionar depois de revisar melhor

    • Fui salvar nos favoritos, mas descobri que já tinha guardado em dezembro de 2023
    • Os repositórios do Nick são sempre de altíssimo nível. Eu também os cito bastante no meu material. Obrigado por compartilhar publicamente
    • Usei esse template em um projeto alguns anos atrás, e ele foi excelente
    • Quando vi a adição recente de uv, deu para perceber que o projeto continua sendo mantido com consistência

  • A filosofia “batteries included” do Django combina perfeitamente com geração de código por IA
    Painel administrativo, login, redefinição de senha e outros recursos básicos já vêm muito bem resolvidos, então a IA consegue criar um site completo mesmo com uma codebase pequena
    Como o código é pequeno e claro, também fica fácil para a IA melhorá-lo iterativamente

    • A vantagem do Django é sua estrutura de código fácil para humanos lerem
      Em vez de componentes gigantes, há modelos e templates claros, então também é mais fácil revisar código gerado por IA
      Além disso, o Django admin existe como uma ground truth independente, então mesmo que o frontend quebre ainda dá para lidar com os dados
      Só acho uma pena que o ecossistema Python não tenha adotado o modelo gevent. Se tivesse adotado, a transição para o assíncrono teria sido muito mais suave
    • Graças à estrutura de INSTALLED_APPS do Django, é fácil adicionar ou remover funcionalidades por app
      É muito mais integrado do que frameworks acoplados de forma frouxa como Flask ou FastAPI
      No fim, essa diferença reduz uma enorme quantidade de pequenos incômodos (papercuts)
    • Já usei tanto Django quanto Rails, e nos testes com Claude Code o Rails funcionou muito melhor
      Reescrevi um app antigo em .NET, e o Rails fez a conversão quase perfeitamente, enquanto o Django teve dificuldade
    • Na verdade, o Ruby on Rails já oferece por padrão há mais tempo recursos como CSP, background workers e várias outras funcionalidades
    • O Django é usado há tanto tempo em projetos open source que existe uma enorme quantidade de dados de código para a IA aprender

  • O recurso de template partials deste lançamento parece bem interessante
    Mas a situação das type annotations continua desconfortável
    O django-stubs exige um plugin do mypy, o django-types é um fork para pyright mas não fica bem sincronizado
    E o pylance usa ainda outro fork próprio
    Espero que na próxima versão pelo menos tipos básicos como HttpRequest, HttpResponse, View e Model sejam incluídos oficialmente

  • Graças ao Django, desenvolver para web foi realmente divertido
    Mesmo quando migro para outros frameworks, sempre acabo voltando para o Django. Foi uma escolha sem arrependimentos

    • Tive a mesma experiência com Ruby on Rails
      Mesmo testando outros frameworks, acabo voltando por causa da praticidade do Rails
      Só é uma pena que o Rails não tenha uma Admin UI nativa
    • Se olhar só para o backend, Django é excelente, mas no lado do frontend ele ainda está na idade da pedra
      Se você quer um full stack completo, é melhor olhar para Laravel ou Rails
    • Sinceramente, nunca entendi muito bem o apelo do Django
      Trabalho com web desde a era do PHP, e o Django sempre me pareceu apenas ok

  • Django foi meu primeiro grande projeto freelance e ainda hoje me passa uma sensação de familiaridade
    Fiz várias tentativas experimentais com ele, e sempre funcionou bem. Sou grato ao Django

  • Há quase 15 anos uso Django quase exclusivamente
    Tentei vários outros frameworks, mas nenhum encaixou tão bem nas mãos quanto o Django
    Nesta release foi adicionado o task framework, mas é uma pena que ele não venha com backend e worker incluídos
    Preferia que entrasse numa forma completa na próxima versão

    • Fico curioso se o Django pretende mesmo cruzar essa linha. Pela filosofia do framework, imagino que valorize manter esses limites
    • Não se pode deixar que a perfeição seja inimiga do bom. No fim, o Django é um framework para “perfeccionistas com prazo”

  • A configuração batteries included do Django o torna adequado para qualquer projeto, independentemente do tamanho
    Meus aplausos à equipe e aos contribuidores

  • Fico curioso sobre como entramos na era das SPAs. Será que foi só para eliminar spinners de carregamento, ou havia uma razão mais profunda?

    • Um dos motivos centrais foi o surgimento dos apps móveis
      Quando web, iOS e Android passaram a compartilhar um mesmo backend, o padrão SPA se espalhou naturalmente
      Eu ainda faço SPAs, mas um dia gostaria de tocar um projeto grande com Django + htmx
    • No passado, migrei para SPA ao fazer visualização de dados com Angular
      Era atraente ter algo funcionando como app sem recarregar a página, mas na prática muitas vezes ainda era preciso dar um hard refresh
      Mesmo assim, acho elegante a estrutura que separa dados e apresentação
    • A web foi criada originalmente para renderização de documentos, mas os usuários queriam aplicativos
      Então surgiram várias tentativas de transformar documentos em apps com JS
    • Na época em que a internet era lenta e a validação no backend demorava, começou-se a adicionar JS para validação de formulários, e isso foi se tornando mais complexo
      No fim, frontend e backend foram separados, e surgiram contratos de API e processos de validação
      Depois apareceu um movimento para reunir tudo de novo com server components, e é exatamente nesse ponto que estamos agora
      Como referência, um exemplo de webform no estilo antigo pode ser visto neste link
    • Templates como os do Django ou Rails careciam de segurança de tipos
      Por isso passei a preferir um processo de build baseado em TypeScript

  • Toda vez que uso Django, sinto simplesmente alegria. É só isso.