field e default_factory: valores mutáveis

Por que uma lista não pode ser padrão direto

Há uma armadilha clássica em Python: usar um valor mutável, como uma lista, de valor padrão. Se o padrão fosse uma única lista criada uma vez, todas as instâncias sem valor explícito acabariam compartilhando a mesma lista. Alterar a lista de um objeto mudaria a de todos os outros, um bug difícil de rastrear. A dataclass conhece esse perigo e simplesmente proíbe: se você tentar usar uma lista como default direto, o Python levanta um erro na definição da classe.

from dataclasses import dataclass

# Isto levanta erro ao definir a classe:
# @dataclass
# class Carrinho:
#     itens: list[str] = []   # ValueError: mutable default

# O Python impede porque a lista seria compartilhada entre instancias.
# A solucao correta esta na proxima secao, com default_factory.

Uma lista como default direto é barrada: evitaria o bug do estado compartilhado.

default_factory cria um valor novo por instância

A solução é o field com default_factory. Em vez de dar um valor pronto, você dá uma função que produz o valor. A dataclass chama essa função a cada nova instância, gerando um objeto novo toda vez. Para uma lista vazia, a factory é a própria função list; para um dicionário vazio, é dict. Assim cada objeto ganha a sua lista, e alterar uma não afeta as outras. É o jeito correto e seguro de ter coleções como campo padrão.

from dataclasses import dataclass, field

@dataclass
class Carrinho:
    dono: str
    itens: list[str] = field(default_factory=list)

c1 = Carrinho("Ana")
c2 = Carrinho("Beto")
c1.itens.append("cafe")

print(c1.itens)  # ['cafe']
print(c2.itens)  # []  <- lista independente, sem contagio

field(default_factory=list) dá a cada carrinho a sua própria lista vazia.

No exemplo, c1 e c2 têm listas independentes. Adicionar cafe ao carrinho de Ana não toca no de Beto, exatamente como se espera. A factory list é chamada duas vezes, uma para cada instância, produzindo duas listas distintas. Você pode passar qualquer função sem argumentos como factory, inclusive uma sua, por exemplo uma que devolva um dicionário já com valores iniciais.

Outros usos do field

Além do default_factory, o field configura outros detalhes de um campo. Você pode marcar um campo para não entrar na comparação de igualdade, útil quando ele guarda algo como um cache que não define a identidade do objeto. Pode marcar um campo para ficar fora do __repr__, escondendo dados sensíveis da representação. E pode declarar um campo que não vai para o __init__, sendo preenchido no __post_init__, tema da próxima aula. O field é o ponto de ajuste fino de cada campo.

Na prática, o default_factory é de longe o uso mais comum do field, porque coleções como campo aparecem o tempo todo. Guarde a regra: valor imutável, como número ou texto, pode ser default direto; valor mutável, como lista ou dict, pede default_factory. Com isso você modela estruturas ricas sem cair na armadilha do estado compartilhado, e a próxima aula fecha o assunto de robustez com imutabilidade e validação.