__init_subclass__: o atalho para quase tudo

Reagir quando nasce uma subclasse

Introduzido no Python 3.6, o __init_subclass__ é um dos ganchos mais úteis e menos conhecidos da linguagem. A ideia é simples: você define esse método na classe-mãe e, a partir daí, toda vez que alguém cria uma subclasse, o Python chama automaticamente o __init_subclass__ da mãe, passando a nova subclasse. É a mesma reação que o exemplo de registro com metaclass alcançava na segunda aula, só que sem a complexidade de escrever uma type personalizada. Para a maioria dos casos, é a resposta certa.

class Plugin:
    registro = {}

    def __init_subclass__(cls, /, nome=None, **kwargs):
        super().__init_subclass__(**kwargs)
        chave = nome or cls.__name__.lower()
        Plugin.registro[chave] = cls

class ExportaCsv(Plugin, nome="csv"):
    pass

class ExportaJson(Plugin):
    pass

print(list(Plugin.registro))  # ['csv', 'exportajson']

Registro automático de subclasses sem metaclass, com um argumento opcional na declaração.

Além de mais simples que a metaclass, este exemplo mostra um bônus: __init_subclass__ pode receber argumentos passados na própria declaração da subclasse. Repare em class ExportaCsv(Plugin, nome='csv'): esse nome='csv' chega ao método como parâmetro. É uma forma limpa de personalizar cada subclasse sem escrever código extra dentro dela. A subclasse ExportaJson, que não passou nome, cai no padrão baseado no nome da classe. Frameworks modernos preferem esse gancho justamente por ser legível.

Validar o contrato das subclasses

Outro uso comum é garantir que toda subclasse cumpra uma regra no momento em que é definida, e não mais tarde, quando um objeto for usado. Isso desloca o erro para o instante mais cedo possível, alinhado com a programação defensiva que o próximo módulo detalha. Se uma subclasse esquecer de definir um atributo obrigatório, o programa recusa a própria definição da classe, com uma mensagem clara, em vez de falhar de forma obscura horas depois.

class Comando:
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        if not hasattr(cls, "nome") or not isinstance(cls.nome, str):
            raise TypeError(
                f"{cls.__name__} precisa definir um atributo nome (texto)"
            )

class Ajuda(Comando):
    nome = "ajuda"   # ok

try:
    class Quebrado(Comando):  # esqueceu o nome
        pass
except TypeError as e:
    print("recusado:", e)  # recusado: Quebrado precisa definir um atributo nome (texto)

O contrato é checado quando a subclasse é criada, falhando cedo e com clareza.

Este é o tipo de garantia que dá tranquilidade em bases de código maiores. A classe Ajuda passa porque define nome; a classe Quebrado é recusada no ato da definição, com uma mensagem que aponta exatamente o que falta. Sem esse gancho, o erro só apareceria quando alguém tentasse usar o comando, longe da causa. Com ele, o problema estoura ao lado do defeito. E, de novo, sem metaclass: um método na classe-mãe basta.

Escolhendo a ferramenta certa

Esta tabela resume a mensagem do módulo. Diante de um problema de metaprogramação, percorra as opções de cima para baixo. Precisa reagir a subclasses? __init_subclass__. Precisa ajustar uma classe pronta? Um decorador de classe. Precisa mediar o acesso a um atributo? Um descritor ou property. Só quando nenhuma dessas serve, e você consegue justificar por escrito, uma metaclass entra em cena. Essa disciplina mantém o código legível para quem vem depois, que é o verdadeiro teste de bom código.