Todo o código do capítulo "Metaprogramação de Classes" da primeira edição do Python Fluente ainda funciona corretamente. Entretanto, alguns dos exemplos antigos não representam mais as soluções mais simples, tendo em vista os novos recursos surgidos desde o Python 3.6.

Substituí aqueles exemplos por outros, enfatizando os novos recursos de metaprogramação ou acrescentando novos requisitos para justificar o uso de técnicas mais avançadas. Alguns destes novos exemplos se valem de dicas de tipo para fornecer fábricas de classes similares ao decorador @dataclass e a typing.NamedTuple.

A Metaclasses no mundo real é nova, trazendo algumas considerações de alto nível sobre a aplicabilidade das metaclasses.

Vamos começar revisando os atributos e métodos definidos no Modelo de Dados do Python para todas as classes.

Como acontece com a maioria das entidades programáticas do Python, classes também são objetos. Toda classe tem alguns atributos definidos no Modelo de Dados do Python, documentados na seção "4.13. Atributos Especiais" do capítulo "Tipos Embutidos" da Biblioteca Padrão do Python. Três destes atributos já apareceram várias vezes no livro: __class__, __name__, and __mro__. Outros atributos de classe padrão são:

cls.__bases__

A tupla de classes base da classe.

cls.__qualname__

O nome qualificado de uma classe ou função, que é um caminho pontuado, desde o escopo global do módulo até a definição da classe. Isso é relevante quando a classe é definida dentro de outra classe. Por exemplo, em um modelo de classe Django, tal como Ox (EN), há uma classe interna chamada Meta. O __qualname__ de Meta é Ox.Meta, mas seu __name__ é apenas Meta. A especificação para este atributo está na PEP 3155—​Qualified name for classes and functions (PEP 3155—Nome qualificado para classes e funções) (EN).

cls.__subclasses__()

Este método devolve uma lista das subclasses imediatas da classe. A implementação usa referências fracas, para evitar referências circulares entre a superclasse e suas subclasses—que mantêm uma referência forte para a superclasse em seus atributos __bases__. O método lista as subclasses na memória naquele momento. Subclasses em módulos ainda não importados não aparecerão no resultado.

cls.mro()

O interpretador invoca este método quando está criando uma classe, para obter a tupla de superclasses armazenada no atributo __mro__ da classe. Uma metaclasse pode sobrepor este método, para personalziar a ordem de resolução de métodos da classe em construção.

Agora, se classe é um objeto, o que é a classe de uma classe?

Nós normalmente pensamos em type como uma função que devolve a classe de um objeto, porque é isso que type(my_object) faz: devolve my_object.class.

Entretanto, type é uma classe que cria uma nova classe quando invocada com três argumentos.

Considere essa classe simples:

Usando o construtor type, podemos criar MyClass durante a execução, com o seguinte código:

Aquela chamada a type é funcionalmente equivalente ao bloco sob a instrução class MyClass… anterior.

Quando o Python lê uma instrução class, invoca type para construir um objeto classe com os parâmetros abaixo:

name

O identificador que aparece após a palavra-chave class, por exemplo, MyClass.

bases

A tupla de superclasses passadas entre parênteses após o identificador da classe, ou (object,), caso nenhuma superclasse seja mencionada na instrução class.

dict

Um mapeamento entre nomes de atributo e valores. Invocáveis se tornam métodos, como vimos na [methods_are_descriptors_sec]. Outros valores se tornam atributos de classe.

A classe type é uma metaclasse: uma classe que cria classes. Em outras palavras, instâncias da classe type são classes. A biblioteca padrão contém algumas outras metaclasses, mas type é a default:

Vamos criar metaclasses personalizadas na Introdução às metaclasses.

Agora, vamos usar a classe embutida type para criar uma função que constrói classes.

A biblioteca padrão contém uma função fábrica de classes que já apareceu várias vezes aqui: collections.namedtuple. No [data_class_ch] também vimos typing.NamedTuple e @dataclass. Todas essas fábricas de classe usam técnicas que veremos neste capítulo.

Vamos começar com uma fábrica muito simples, para classes de objetos mutáveis—a substituta mais simples possível de @dataclass.

Suponha que eu esteja escrevendo uma aplicação para uma pet shop, e queira armazenar dados sobre cães como registros simples. Mas não quero escrever código padronizado como esse:

Chato…​ cada nome de campo aparece três vezes, e essa repetição sequer nos garante um bom repr:

Inspirados por collections.namedtuple, vamos criar uma record_factory, que cria classes simples como Dog em tempo real. O Exemplo 1 mostra como ela deve funcionar.

1. A fábrica pode ser chamada como namedtuple: nome da classe, seguido dos nomes dos atributos separados por espaços, em um única string.

2. Um repr agradável.

3. Instâncias são iteráveis, então elas podem ser convenientemente desempacotadas em uma atribuição…​

4. …​ou quando são passadas para funções como format.

5. Uma instância do registro é mutável.

6. A classe recém-criada herda de object—não tem qualquer relação com nossa fábrica.

O código para record_factory está no Exemplo 2.^[3]

1. O usuário pode fornecer os nomes dos campos como uma string única ou como um iterável de strings.

2. Aceita argumentos como os dois primeiros de collections.namedtuple; devolve type—isto é, uma classe que se comporta como uma tuple.

3. Cria uma tupla de nomes de atributos; esse será o atributo __slots__ da nova classe.

4. Essa função se tornará o método __init__ na nova classe. Ela aceita argumentos posicionais e/ou nomeados.^[4]

5. Produz os valores dos campos na ordem dada por __slots__.

6. Produz um repr agradável, iterando sobre __slots__ e self.

7. Monta um dicionário de atributos de classe.

8. Cria e devolve a nova classe, invocando o construtor de type.

9. Converte names separados por espaços ou vírgulas em uma lista de str.

O Exemplo 2 é a primeira vez que vemos type em uma dica de tipo. Se a anotação fosse apenas → type, significaria que record_factory devolve uma classe—e isso estaria correto. Mas a anotação → type[tuple] é mais precisa: indica que a classe devolvida será uma subclasse de tuple.

A última linha de record_factory no Exemplo 2 cria uma classe cujo nome é o valor de cls_name, com object como sua única classe base imediata, e um espaço de nomes carregado com __slots__, __init__, __iter__, e __repr__, sendo os útimos três métodos de instância.

Poderíamos ter dado qualquer outro nome ao atributo de classe __slots__, mas então teríamos que implementar __setattr__ para validar os nomes dos atributos em uma atribuição, porque em nossas classes similares a registros queremos que o conjunto de atributos seja sempre o mesmo e na mesma ordem. Entretanto, lembre-se que a principal característica de __slots__ é economizar memória quando estamos lidando com milhões de instâncias, e que usar __slots__ traz algumas desvantagens, discutidas na [slots_section].

Vamos ver agora como emular fábricas de classes mais modernas, como typing.NamedTuple, que recebe uma classe definida pelo usuário, escrita com o comando class, e a melhora automaticamente, acrescentando funcionalidade.

Tanto __init_subclass__ quanto __set_name__ foram propostos na PEP 487—Simpler customization of class creation (PEP 487—Uma personalização mais simples da criação de classes). Falamos pela primeira vez do método especial para descritores __set_name__ na [auto_storage_sec]. Agora vamos estudar __init_subclass__.

No [data_class_ch], vimos como typing.NamedTuple e @dataclass permitem a programadores usarem a instrução class para especificar atributos para uma nova classe, que então é aperfeiçoada pela fábrica de classes com a adição automática de métodos essenciais, tais como __init__, __repr__, __eq__, etc.

Ambas as fábricas de classes leem as dicas de tipo na instrução class do usuário para aperfeiçoar a classe. Essas dicas de tipo também permitem que verificadores de tipo estáticos validem código que define ou lê aqueles atributos. Entretanto, NamedTuple e @dataclass não se valem das dicas de tipo para validação de atributos durante a execução. A classe Checked, no próximo exemplo, faz isso.

O Exemplo 3 mostra como usar Checked para criar uma classe Movie.

1. Movie herda de Checked—que definiremos mais tarde, no Exemplo 5.

2. Cada atributo é anotado com um construtor. Aqui usei tipos embutidos.

3. Instâncias de Movie devem ser criadas usando argumentos nomeados.

4. Em troca, temos um __repr__ agradável.

Os construtores usados como dicas de tipo podem ser qualquer invocável que receba zero ou um argumento, e devolva um valor adequado ao tipo do campo pretendido ou rejeite o argumento, gerando um TypeError ou um ValueError.

Usar tipos embutidos para as anotações no Exemplo 3 significa que os valores devem aceitáveis pelo construtor do tipo. Para int, isso significa qualquer x tal que int(x) devolva um int. Para str, qualquer coisa serve durante a execução, pois str(x) funciona com qualquer x no Python.^[5]

Quando chamado sem argumentos, o construtor deve devolver um valor default de seu tipo.^[6]

Esse é o comportamento padrão de construtores embutidos no Python:

Em uma subclasse de Checked como Movie, parâmetros ausentes criam instâncias com os valores default devolvidos pelos construtores dos campos. Por exemplo:

Os construtores são usados para validação durante a instanciação, e quando um atributo é definido diretamente em uma instância:

Vamos ver agora a implementação de checkedlib.py. A primeira classe é o descritor Field, como mostra o Exemplo 4.

1. Lembre-se, desde o Python 3.9, o tipo Callable para anotações é a ABC em collections.abc, e não o descontinuado typing.Callable.

2. Essa é a dica de tipo Callable mínima; o parâmetro de tipo e o tipo devolvido para constructor são ambos implicitamente Any.

3. Para verificação durante a execução, usamos o embutido callable.^[7] O teste contra type(None) é necessário porque o Python entende None em um tipo como NoneType, a classe de None (e portanto invocável), mas esse é um construtor inútil, que apenas devolve None.

4. Se Checked.__init__ definir value como …​ (o objeto embutido Ellipsis), invocamos o construtor sem argumentos.

5. Caso contrário, invocamos o constructor com o value dado.

6. Se constructor gerar qualquer dessas exceções, geramos um TypeError com uma mensagem útil, incluindo os nomes do campo e do construtor; por exemplo, 'MMIX' não é compatível com year:int.

7. Se nenhuma exceção for gerada, o value é armazenado no instance.__dict__.

Em __set__, precisamos capturar TypeError e ValueError, pois os construtores embutidos podem gerar qualquer dos dois, dependendo do argumento. Por exemplo, float(None) gera um TypeError, mas float('A') gera um ValueError. Por outro lado, float('8') não causa qualquer erro, e devolve 8.0. E assim eu aqui declaro que, nesse exemplo simples, este um recurso, não um bug.

Vamos agora nos concentrar na classe Checked, que dividi em duas listagens. O Exemplo 5 mostra a parte inicial da classe, incluindo os métodos mais importantes para esse exemplo. O restante dos métodos está no Exemplo 6.

1. Escrevi este método de classe para ocultar a chamada a typing.get_type_hints do resto da classe. Se precisasse suportar apenas versões do Python ≥ 3.10, invocaria inspect.get_annotations em vez disso. Reveja a [problems_annot_runtime_sec] para uma discussão dos problemas com essas funções.

2. __init_subclass__ é chamado quando uma subclasse da classe atual é definida. Ele recebe aquela nova subclasse como seu primeiro argumento—e por isso nomeei o argumento subclass em vez do habitual cls. Para mais informações sobre isso, veja __init_subclass__ não é um método de classe típico.

3. super().__init_subclass__() não é estritamente necessário, mas deve ser invocado para ajudar outras classes que implementem .__init_subclass__() na mesma árvore de herança. Veja a [mro_section].

4. Itera sobre name e constructor em cada campo…​

5. …​criando um atributo em subclass com aquele name vinculado a um descritor Field, parametrizado com name e constructor.

6. Para cada name nos campos da classe…​

7. …​obtém o value correspondente de kwargs e o remove de kwargs. Usar …​ (o objeto Ellipsis) como default nos permite distinguir entre argumentos com valor None de argumentos ausentes.^[8]

8. Essa chamada a setattr aciona Checked.__setattr__, apresentado no Exemplo 6.

9. Se houver itens remanescentes em kwargs, seus nomes não correspondem a qualquer dos campos declarados, e __init__ vai falhar.

10. Esse erro é informado por __flag_unknown_attrs, listado no Exemplo 6. Ele recebe um argumento *names com os nomes de atributos desconhecidos. Usei um único asterisco em *kwargs, para passar suas chaves como uma sequência de argumentos.

Vamos examinar os métodos restantes da classe Checked, continuando do Exemplo 5. Observe que prefixei os nomes dos métodos _fields e _asdict com _, pela mesma razão pela qual isso é feito na API de collections.namedtuple: reduzir a possibilidade de colisões de nomes com nomes de campos definidos pelo usuário.

1. Intercepta qualquer tentativa de definir um atributo de instância. Isso é necessário para evitar a definição de um atributo desconhecido.

2. Se o name do atributo é conhecido, busca o descriptor correspondente.

3. Normalmente não é preciso invocar o __set__ do descritor explicitamente. Nesse caso isso foi necessário porque __setattr__ intercepta todas as tentativas de definir um atributo em uma instância, mesmo na presença de um descritor dominante, tal como Field.^[10]

4. Caso contrário, o atributo name é desconhecido, e uma exceção será gerada por __flag_unknown_attrs.

5. Cria uma mensagem de erro útil, listando todos os argumentos inesperados, e gera um AttributeError. Este é um raro exemplo do tipo especial NoReturn, tratado na [noreturn_sec].

6. Cria um dict a partir dos atributos de um objeto Movie. Eu chamaria este método de _as_dict, mas segui a convenção iniciada com o método _asdict em collections.namedtuple.

7. Implementar um __repr__ agradável é a principal razão para ter _asdict neste exemplo.

O exemplo Checked mostra como tratar descritores dominantes ao implementar __setattr__ para bloquear a definição arbitrária de atributos após a instanciação. É possível debater se vale a pena implementar __setattr__ neste exemplo. Sem ele, definir movie.director = 'Greta Gerwig' funcionaria, mas o atributo director não seria verificado de forma alguma, não apareceria no __repr__ nem seria incluído no dict devolvido por _asdict—ambos definidos no Exemplo 6.

Em record_factory.py (no Exemplo 2), solucionei essa questão usando o atributo de classe __slots__. Entretanto, essa solução mais simples não é viável aqui, como explicado a seguir.

Um decorador de classes é um invocável que se comporta de forma similar a um decorador de funções: recebe uma classe decorada como argumento, e deve devolver um classe para substituir a classe decorada. Decoradores de classe frequentemente devolvem a própria classe decorada, após injetar nela mais métodos pela definição de atributos. Provavelmente, a razão mais comum para escolher um decorador de classes, em vez do mais simples __init_subclass__, é evitar interferência com outros recursos da classe, tais como herança e metaclasses.^[11]

Nessa seção vamos estudar checkeddeco.py, que oferece a mesma funcionalidade de checkedlib.py, mas usando um decorador de classe. Como sempre, começamos examinando um exemplo de uso, extraído dos doctests em checkeddeco.py (no Exemplo 7).

A única diferença entre o Exemplo 7 e o Exemplo 3 é a forma como a classe Movie é declarada: ela é decorada com @checked em vez de ser uma subclasse de Checked. Fora isso, o comportamento externo é o mesmo, incluindo a validação de tipo e a atribuição de valores default, apresentados após o Exemplo 3, na Apresentando __init_subclass__.

Vamos olhar agora para a implementação de checkeddeco.py. As importações e a classe Field são as mesmas de checkedlib.py, listadas no Exemplo 4. Em checkeddeco.py não há qualquer outra classe, apenas funções.

A lógica antes implementada em __init_subclass__ agora é parte da função checked—o decorador de classes listado no Exemplo 8.

1. Lembre-se que classes são instâncias de type. Essas dicas de tipo sugerem fortemente que este é um decorador de classes: ele recebe uma classe e devolve uma classe.

2. _fields agora é uma função de alto nível definida mais tarde no módulo (no Exemplo 9).

3. Substituir cada atributo devolvido por _fields por uma instância do descritor Field é o que __init_subclass__ fazia no Exemplo 5. Aqui há mais trabalho a ser feito…​

4. Cria um método de classe a partir de _fields, e o adiciona à classe decorada. O comentário type: ignore é necessário, porque o Mypy reclama que type não tem um atributo _fields.

5. Funções ao nível do módulo, que se tornarão métodos de instância da classe decorada.

6. Adiciona cada um dos instance_methods a cls.

7. Devolve a cls decorada, cumprindo o contrato básico de um decorador de classes.

Todas as funções no primeiro nível de checkeddeco.py estão prefixadas com um sublinhado, exceto o decorador checked. Essa convenção para a nomenclatura faz sentido por duas razões:

• checked é parte da interface pública do módulo checkeddeco.py, as outras funções não.

• As funções no Exemplo 9 serão injetadas na classe decorada, e o _ inicial reduz as chances de um conflito de nomes com atributos e métodos definidos pelo usuário na classe decorada.

O restante de checkeddeco.py está listado no Exemplo 9. Aquelas funções no nível do módulo contém o mesmo código dos métodos correspondentes na classe Checked de checkedlib.py. Elas foram explicadas no Exemplo 5 e no Exemplo 6.

Observe que a função _fields exerce dois papéis em checkeddeco.py. Ela é usada como uma função regular na primeira linha do decorador checked e será também injetada como um método de classe na classe decorada.

O módulo checkeddeco.py implementa um decorador de classes simples mas usável. O @dataclass do Python faz muito mais. Ele suporta várias opções de configuração, acrescenta mais métodos à classe decorada, trata ou avisa sobre conflitos com métodos definidos pelo usuário na classe decorada, e até percorre o __mro__ para coletar atributos definidos pelo usuário declarados em superclasses da classe decorada. O código-fonte do pacote dataclasses no Python 3.9 tem mais de 1200 linhas.

Para fazer metaprogramação de classes, precisamos saber quando o interpretador Python avalia cada bloco de código durante a criação de uma classe. É disso que falaremos a seguir.

Programadores Python falam de "importação" (import time) versus "execução" (runtime), mas estes termos não tem definições precisas e há uma zona cinzenta entre eles.

Na importação, o interpretador:

1. Analisa o código-fonte de módulo .py em uma passagem, de cima até embaixo. É aqui que um SyntaxError pode ocorrer.

2. Compila o bytecode a ser executado.

3. Executa o código no nível superior do módulo compilado.

Se existir um arquivo .pyc atualizado no __pycache__ local, a análise e a compilação são omitidas, pois o bytecode está pronto para ser executado.

Apesar da análise e a compilação serem definitivamente atividades de "importação", outras coisas podem acontecer durante o processo, pois quase todos os comandos ou instruções no Python são executáveis, no sentido de poderem potencialmente rodar código do usuário e modificar o estado do programa do usuário.

Em especial, a instrução import não é meramente uma declaração^[12], pois na verdade ela executa todo o código no nível superior de um módulo, quando este é importado para o processo pela primeira vez. Importações posteriores do mesmo módulo usarão um cache, e então o único efeito será a vinculação dos objetos importados a nomes no módulo cliente. Aquele código no primeiro nível pode fazer qualquer coisa, incluindo ações típicas da "execução", tais como escrever em um arquivo de log ou conectar-se a um banco de dados.^[13] Por isso a fronteira entre a "importação" e a "execução" é difusa: import pode acionar todo tipo de comportamento de "execução", porque a instrução import e a função embutida __import__() podem ser usadas dentro de qualquer função regular.

Tudo isso é bastante abstrato e sútil, então vamos realizar alguns experimentos para ver o que acontece, e quando.

[Metaclasses] são uma mágica tão profunda que 99% dos usuários jamais deveria se preocupar com elas. Quem se pergunta se precisa delas, não precisa (quem realmente precisa de metaclasses sabe disso com certeza, e não precisa que lhe expliquem a razão).^[14]

Uma metaclasse é uma fábrica de classes. Diferente de record_factory, do Exemplo 2, uma metaclasse é escrita como uma classe. Em outras palavras, uma metaclasse é uma classe cujas instâncias são classes. A Figura 1 usa a Notação Engenhocas e Bugigangas para representar uma metaclasse: uma engenhoca que produz outra engenhoca.

Pense no modelo de objetos do Python: classes são objetos, portanto cada classe deve ser uma instância de alguma outra classe. Por default, as classes do Python são instâncias de type. Em outras palavras, type é a metaclasse da maioria das classes, sejam elas embutidas ou definidas pelo usuário:

Para evitar regressões infinitas, a classe de type é type, como mostra a última linha.

Observe que não estou dizendo que str ou LineItem são subclasses de type. Estou dizendo que str e LineItem são instâncias de type. Elas são todas subclasses de object. A Figura 2 pode ajudar você a contemplar essa estranha realidade.

O próximo trecho mostra que a classe de collections.Iterable é abc.ABCMeta. Observe que Iterable é uma classe abstrata, mas ABCMeta é uma classe concreta—​afinal, Iterable é uma instância de ABCMeta:

Por fim, a classe de ABCMeta também é type. Toda classe é uma instância de type, direta ou indiretamente, mas apenas metaclasses são também subclasses de type. Essa é a mais importante relação para entender as metaclasses: uma metaclasse, tal como ABCMeta, herda de type o poder de criar classes. A Figura 3 ilustra essa relação fundamental.

A lição importante aqui é que metaclasses são subclasses de type, e é isso que permite a elas funcionarem como fábricas de classes. Uma metaclasse pode personalizar suas instâncias implementando métodos especiais, como demosntram as próximas seções.

Não quero encorajar a otimização prematura nem excessos de engenharia, então aqui temos um cenário de faz de conta para justificar a reescrever checkedlib.py com __slots__, exigindo a aplicação de uma metaclasse. Sinta-se a vontade para pular a historinha.

O módulo metaclass/checkedlib.py, que estudaremos a seguir, é um substituto instantâneo para initsub/checkedlib.py. Os doctests embutidos nos dois módulos são idênticos, bem como os arquivos checkedlib_test.py para o pytest.

A complexidade de checkedlib.py é ocultada do usuário. Aqui está o código-fonte de um script que usa o pacote:

Essa definição concisa da classe Movie se vale de três instâncias do descritor de validação Field, uma configuração de __slots__, cinco métodos herdados de Checked e uma metaclasse para juntar tudo isso. A única parte visível de checkedlib é a classe base Checked.

Observe a Figura 4. A Notação Engenhocas e Bugigangas complementa o diagrama de classes UML, tornando mais visível a relação entre classes e instâncias.

Por exemplo, uma classe Movie usando a nova checkedlib.py é uma instância de CheckedMeta e uma subclasse de Checked. Adicionalmente, os atributos de classe title, year e box_office de Movie são três instâncias diferentes de Field. Cada instância de Movie tem seus próprios atributos _title, _year e _box_office, para armazenar os valores dos campos correspondentes.

Vamos agora estudar o código, começando pela classe Field, exibida no Exemplo 21.

A classe descritora Field agora está um pouco diferente. Nos exemplos anteriores, cada instância do descritor Field armazenava seu valor na instância gerenciada, usando um atributo de mesmo nome. Por exemplo, na classe Movie, o descritor title armazenava o valor do campo em um atributo title na instância gerenciada. Isso tornava desnecessário que Field implementasse um método __get__.

Entretanto, quando uma classe como Movie usa __slots__, ela não pode ter atributos de classe e atributos de instância com o mesmo nome. Cada instância do descritor é um atributo de classe, e agora precisamos de atributos de armazenamento separados em cada instância. O código usa o nome do descritor prefixado por um único _. Portanto, instâncias de Field têm atributos name e storage_name distintos, e implementamos Field.__get__.

O Exemplo 21 mostra o código-fonte de Field, com os textos explicativos descrevendo apenas as mudanças nessa versão.

1. Determina storage_name a partir do argumento name.

2. Se __get__ recebe None como argumento instance, o descritor está sendo lido desde a própria classe gerenciada, não de uma instância gerenciada. Neste caso devolvemos o descritor.

3. Caso contrário, devolve o valor armazenado no atributo chamado storage_name.

4. __set__ agora usa setattr para definir ou atualizar o atributo gerenciado.

O Exemplo 22 mostra o código para a metaclasse que controla este exemplo.

1. __new__ é o único método implementado em CheckedMeta.

2. Só melhora a classe se seu cls_dict não incluir __slots__. Se __slots__ já está presente, assume que essa é a classe base Checked e não uma subclasse definida pelo usuário, e cria a classe sem modificações.

3. Nos exemplos anteriores usamos typing.get_type_hints para obter as dicas de tipo, mas aquilo exige um classe existente como primeiro argumento. Neste ponto, a classe que estamos configurando ainda não existe, então precisamos recuperar __annotations__ diretamente do cls_dict—o espaço de nomes da classe em construção, que o Python passa como último argumento para o __new__ da metaclasse.

4. Itera sobre type_hints para…​

5. …​criar um Field para cada atributo anotado…​

6. …​sobrescreve o item correspondente em cls_dict com a instância de Field…​

7. …​e acrescenta o storage_name do campo à lista que usaremos para…​

8. …​preencher o __slots__ no cls_dict—o espaço de nomes da classe em construção.

9. Por fim, invocamos super().__new__.

A última parte de metaclass/checkedlib.py é a classe base Checked, a partir da qual os usuários dessa biblioteca criarão subclasses para melhorar suas classes, como Movie.

O código desta versão de Checked é o mesmo da Checked em initsub/checkedlib.py (listada no Exemplo 5 e no Exemplo 6), com três modificações:

1. O acréscimo de um __slots__ vazio, para sinalizar a CheckedMeta.__new__ que esta classe não precisa de processamento especial.

2. A remoção de __init_subclass__, cujo trabalho agora é feito por CheckedMeta.__new__.

3. A remoção de __setattr__, que se tornou redundante: o acréscimo de __slots__ à classe definida pelo usuário impede a definição de atributos não declarados.

O Exemplo 23 é a listagem completa da versão final de Checked.

Isso conclui nossa terceira versão de uma fábrica de classes com descritores validados.

A próxima seção trata de algumas questões gerais relacionadas a metaclasses.

Metaclasses são poderosas mas complexas. Antes de se decidir a implementar uma metaclasse, considere os pontos a seguir.

Quando atualizei esse capítulo para a segunda edição, precisava encontrar exemplos simples mas reveladores, para substituir o código de LineItem no exemplo da loja de comida a granel, que não precisava mais de metaclasses desde o Python 3.6.

A ideia de metaclasse mais interessante e mais simples me foi dada por João S. O. Bueno—mais conhecido como JS na comunidade Python brasileira. Uma aplicação de sua ideia é criar uma classe que gera constantes numéricas automaticamente:

Sim, esse código funciona como exibido! Aquilo acima é um doctest em autoconst_demo.py.

Aqui está a classe base fácil de usar AutoConst , e a metaclasse por trás dela, implementadas em autoconst.py:

É só isso.

Claramente, o truque está em WilyDict.

Quando o Python processa o espaço de nomes da classe do usuário e lê banana, ele procura aquele nome no mapeamento fornecido por __prepare__: uma instância de WilyDict. WilyDict implementa __missing__, tratado na [missing_method]. A instância de WilyDict inicialmente não contém uma chave 'banana', então o método __missing__ é acionado. Ele cria um item em tempo real, com a chave 'banana' e o valor 0, e devolve esse valor. O Python se contenta com isso, e daí tenta recuperar 'coconut'. WilyDict imediatamente adiciona aquele item com o valor 1, e o devolve. O mesmo acontece com 'vanilla', que é então mapeado para 2.

Já vimos __prepare__ e __missing__ antes. A verdadeira inovação é a forma como JS as juntou.

Aqui está o código-fonte de WilyDict, também de autoconst.py:

Enquanto experimentava, descobri que o Python procurava __name__ no espaço de nomes da classe em construção, fazendo com que WilyDict acrescentasse um item __name__ e incrementasse __next_value. Eu então inseri uma instrução if em __missing__, para gerar um KeyError para chaves que se parecem com atributos dunder.

O pacote autoconst.py tanto exige quanto ilustra o mecanismo de criação dinâmica de classes do Python.

Me diverti muito adicionando mais funcionalidades a AutoConstMeta e AutoConst, mas em vez de compartilhar meus experimentos, vou deixar vocês se divertirem, brincando com o hack genial de JS.

Aqui estão algumas ideias:

• Torne possivel obter o nome da constante a partir do valor. Por exemplo, Flavor[2] devolveria 'vanilla'. Você pode fazer isso implementando __getitem__ em AutoConstMeta. Desde o Python 3.9, épossível implementar __class_getitem__ na própria AutoConst.

• Suporte a iteração sobre a classe, implementando __iter__ na metaclasse. Eu faria __iter__ produzir as constantes na forma de pares (name, value).

• Implemente uma nova variante de Enum. Isso seria um empreeendimento complexo, pois o pacote enum está cheio de armadilhas, incluindo a metaclasse EnumMeta, com centenas de linhas de código e um método __prepare__ nem um pouco trivial.

Divirta-se!

Metaclasses, bem como decoradores de classes e __init_subclass__, são úteis para:

• Registro de subclasses

• Validação estrutural de subclasses

• Aplicar decoradores a muitos métodos ao mesmo tempo

• Serialização de objetos

• Mapeamento objeto-relacional

• Persistência baseada em objetos

• Implementar métodos especiais a nível de classe

• Implementar recursos de classes encontrados em outras linguagens, tal como traits (traços) (EN) e programação orientada a aspecto

Em alguns casos, a metaprogramação de classes também pode ajudar em questões de desempenho, executando tarefas no momento da importação que de outra forma seriam executadas repetidamente durante a execução.

Para finalizar, vamos nos lembrar do conselho final de Alex Martelli em seu ensaio [waterfowl_essay]:

E não defina ABCs personalizadas (ou metaclasses) em código de produção. Se você sentir uma forte necessidade de fazer isso, aposto que é um caso da síndrome de "todos os problemas se parecem com um prego" em alguém que acabou de ganhar um novo martelo brilhante - você ( e os futuros mantenedores de seu código) serão muito mais felizes se limitando a código simples e direto, e evitando tais profundezas.

Acredito que o conselho de Martelli se aplica não apenas a ABCs e metaclasses, mas também a hierarquias de classe, sobrecarga de operadores, decoradores de funções, descritores, decoradores de classes e fábricas de classes usando __init_subclass__.

Em princípio, essas poderosas ferramentas existem para suportar o desenvolvimento de bibliotecas e frameworks. Naturalmente, as aplicações devem usar tais ferramentas, na forma oferecida pela biblioteca padrão do Python ou por pacotes externos. Mas implementá-las em código de aplicações é frequentemente resultado de uma abstração prematura.

Bons frameworks são extraídos, não inventados.^[19]

Este capítulo começou com uma revisão dos atributos encontrados em objetos classe, tais como __qualname__ e o método __subclasses__(). A seguir, vimos como a classe embutida type pode ser usada para criar classes durante a execução.

O método especial __init_subclass__ foi introduzido, com a primeira versão de uma classe base Checked, projetada para substituir dicas de tipo de atributos em subclasses definidas pelo usuário por instâncias de Field, que usam construtores para impor o tipo daqueles atributos durante a execução.

A mesma ideia foi implementada com um decorador de classes @checked, que acrescenta recursos a classes definidas pelo usuário, de forma similar ao que pode ser feito com __init_subclass__. Vimos que nem __init_subclass__ nem um decorador de classes podem configurar __slots__ dinamicamente, pois operam apenas após a criação da classe.

Os conceitos de "[momento/tempo de] importação" e "[momento/tempo de] execução" foram esclarecidos com experimentos mostrando a ordem na qual o código Python é executado quando módulos, descritores, decoradores de classe e __init_subclass__ estão envolvidos.

Nossa exploração de metaclasses começou com um explicação geral de type como uma metaclasse, e sobre como metaclasses definidas pelo usuário podem implementar __new__, para personalziar as classes que criam. Vimos então nossa primeira metaclasse personalizada, o clássico exemplo MetaBunch, usando __slots__. A seguir, outro experimento com o tempo de avaliação demonstrou como os métodos __prepare__ e __new__ de uma metaclasse são invocados mais cedo que __init_subclass__ e decoradores de classe, oferecendo oportunidades para uma personalização de classes mais profunda.

A terceira versão de uma fábrica de classes Checked, com descritores Field e uma configuração personalizada de __slots__ foi apresentada, seguida de considerações gerais sobre o uso de metaclasses na prática.

Por fim, vimos o hack AutoConst, inventado por João S. O. Bueno, baseado na brilhante ideia de uma metaclasse com __prepare__ devolvendo um mapeamento que implementa __missing__. Em menos de 20 linhas de código, autoconst.py demonstra o poder da combinação de técnicas de metaprogramação no Python.

Nunca encontrei outra linguagem como o Python, fácil para iniciantes, prática para profissionais e empolgante para hackers. Obrigado, Guido van Rossum e todos que a fazem ser assim.

Caleb Hattingh—um dos revisores técnicos desse livro—escreveu o pacote autoslot, fornecendo uma metaclasse para a criação automática do atributo __slots__ em uma classe definida pelo usuário, através da inspeção do bytecode de __init__ e da identificação de todas as atribuições a atributos de self. Além de útil, esse pacote é um excelente exemplo para estudo: são apenas 74 linhas de código em autoslot.py, incluindo 20 linhas de comentários que explicam as partes mais difíceis.

As referências essenciais deste capítulo na documentação do Python são "3.3.3. Personalizando a criação de classe" no capítulo "Modelos de Dados" da Referência da Linguagem Python, que cobre __init_subclass__ e metaclasses. A documentação da classe type na página "Funções Embutidas", e "4.13. Atributos especiais" do capítulo "Tipos embutidos" na Biblioteca Padrão do Python também são leituras fundamentais.

Na Biblioteca Padrão do Python, a documentação do módulo types trata de duas funções introduzidas no Python 3.3, que simplificam a metaprogramação de classes: types.new_class and types.prepare_class.

Decoradores de classes foram formalizados na PEP 3129—Class Decorators (Decoradores de Classes) (EN), escrita por Collin Winter, com a implemetação de referência desenvolvida por Jack Diederich. A palestra "Class Decorators: Radically Simple" (Decoradores de Classes: Radicalmente Simples. Aqui o video (EN)), na PyCon 2009, também de Jack Diederich, é uma rápida introdução a esse recurso. Além de @dataclass, um exemplo interessante—e muito mais simples—de decorador de classes na bilbioteca padrão do Python é functools.total_ordering (EN), que gera métodos especiais para comparação de objetos.

Para metaclasses, a principal referência na documentação do Python é a PEP 3115—Metaclasses in Python 3000 (Metaclasses no Python 3000), onde o método especial __prepare__ foi introduzido.

O Python in a Nutshell, 3ª ed., de Alex Martelli, Anna Ravenscroft, e Steve Holden, é uma referência, mas foi escrito antes da PEP 487—Simpler customization of class creation (PEP 487—Uma personalização mais simples da criação de classes) ser publicada. O principal exemplo de metaclasse no livro—MetaBunch—ainda é válido, pois não pode ser escrito com mecanismos mais simples. O Effective Python, 2ª ed. (Addison-Wesley), de Brett Slatkin, traz vários exemplos atualizados de técnicas de criação de classes, incluindo metaclasses.

Para aprender sobre as origens da metaprogramação de classes no Python, recomento o artigo de Guido van Rossum de 2003, "Unifying types and classes in Python 2.2" (Unificando tipos e classes no Python 2.2) (EN). O texto se aplica também ao Python moderno, pois cobre o quê era então chamado de "novo estilo" de semântica de classes—a semântica default no Python 3—incluindo descritores e metaclasses. Uma das referências citadas por Guido é Putting Metaclasses to Work: a New Dimension in Object-Oriented Programming, de Ira R. Forman e Scott H. Danforth (Addison-Wesley), livro para o qual ele deu cinco estrelas na Amazon.com, acrescentando o seguinte comentário:

Este livro contribuiu para o projeto das metaclasses no Python 2.2

Pena que esteja fora de catálogo; sempre me refiro a ele como o melhor tutorial que conheço para o difícil tópico da herança múltipla cooperativa, suportada pelo Python através da função super().^[20]

Se você gosta de metaprogramação, talvez gostaria que o Python suportasse o recurso definitivo de metaprogramação: macros sintáticas, como as oferecidas pela família de linguagens Lisp e—mais recentemente—pelo Elixir e pelo Rust. Macros sintáticas são mais poderosas e menos sujeitas a erros que as macros primitivas de substituição de código da linguagem C. Elas são funções especiais que reescrevem código-fonte para código padronizado, usando uma sintaxe personalizada, antes da etapa de compilação, permitindo a desenvolvedores introduzir novas estruturas na linguagem sem modificar o compilador. Como a sobrecarga de operadores, macros sintáticas podem ser mal usadas. Mas, desde que a comunidade entenda e gerencie as desvantagens, elas suportam abstrações poderosas e amigáveis, como as DSLs (Domain-Specific Languages—Linguagens de Domínio Específico). Em setembro de 2020, Marc Shannon, um dos desenvolvedores principais do Python, publicou a PEP 638—Syntactic Macros (Macros Sintáticas) (EN), defendendo exatamente isso. Um ano após sua publicação inicial (quando escrevo essas linhas), a PEP 638 ainda era um rascunho e não havia discussões contínuas sobre ela. Claramente não é uma prioridade muito alta entre os desenvolvedores principais do Python. Eu gostaria de ver a PEP 638 sendo melhor discutida e, por fim, aprovada. Macros sintáticas permitiriam à comunidade Python experimentar com novos recursos controversos, tal como o "operador morsa" (operador walrus) (PEP 572 (EN)), correspondência/casamento de padrões (PEP 634 (EN)) e regras alternativas para avaliação de dicas de tipo (PEPs 563 (EN) e 649 (EN)), antes que se fizessem modificações permanentes no núcleo da linguagem. Nesse meio tempo, podemos sentir o gosto das macros sintáticas com o pacote MacroPy.