dataclass, NamedTuple, attrs ou pydantic: qual usar de verdade?

Fri, 10 Apr 2026 00:00:00 +0000

Existe um ponto no crescimento de qualquer projeto Python em que os dicionários começam a doer. Não de vez — vai acontecendo aos poucos. Você passa um dict para uma função, a função passa para outra, e em algum momento ninguém mais sabe ao certo quais chaves estão garantidas, qual é o tipo de cada valor, ou o que acontece se uma chave estiver faltando.

def calcular_desconto(pedido: dict) -> float:
    # pedido tem "valor"? "valor_bruto"? "subtotal"?
    # "cliente" é um dict também? tem "nivel"?
    return pedido["valor"] * _fator(pedido["cliente"]["nivel"])

Funciona. Ninguém vai questionar em code review. O problema aparece três meses depois, quando alguém passa um pedido sem a chave "nivel" — ou quando você tenta debugar e o repr do dicionário tem quarenta chaves misturadas.

O .env que você não deveria ter commitado

Mon, 06 Apr 2026 00:00:00 +0000

Existe uma busca no GitHub que retorna milhares de resultados úteis para um atacante: filename:.env DB_PASSWORD. Repositórios públicos com arquivos .env commitados por acidente, contendo senhas de banco, chaves de API, segredos JWT — tudo em texto claro, indexado, pesquisável.

Não é incompetência. É o resultado natural de uma prática que parece razoável: colocar credenciais num arquivo, adicionar esse arquivo ao .gitignore, e confiar que o .gitignore vai proteger. Funciona até o dia que não funciona — um git add . no momento errado, um novo membro do time que clona o repo e cria o .env a partir do .env.example sem perceber que o exemplo já tem valores reais, ou um editor que cria arquivos temporários fora do padrão ignorado.

Pydantic on Blog do Riverfount

dataclass, NamedTuple, attrs ou pydantic: qual usar de verdade?

O .env que você não deveria ter commitado