Protocol: duck typing com garantias em tempo de análise

Protocol: duck typing com garantias em tempo de análise

Você herdou um sistema de cálculo de descontos. Não tem classe base, não tem ABC, não tem interface formal nenhuma. Cada tipo de desconto (cupom, fidelidade, campanha sazonal) é só uma classe qualquer com um método aplicar(pedido) que devolve o valor final. O código que orquestra isso nem sabe que tipo de objeto está recebendo, só chama desconto.aplicar(pedido) e segue em frente. Duck typing raiz: se anda como pato e grasna como pato, aplica desconto como pato. ...

22 de julho de 2026 · 6 min · 1198 words · Riverfount
dataclass, NamedTuple, attrs ou pydantic: qual usar de verdade?

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

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. 1 2 3 4 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. ...

10 de abril de 2026 · 9 min · 1731 words · Riverfount