Esse capítulo é inteiramente novo, escrito para essa segunda edição de Python Fluente. Vamos começar com sobrecargas.

No Python, as funções podem aceitar diferentes combinações de argumentos.

O decorador @typing.overload permite anotar tais combinações. Isto é particularmente importante quando o tipo devolvido pela função depende do tipo de dois ou mais parâmetros.

Considere a função embutida sum. Esse é o texto de help(sum), traduzido:

A função embutida sum é escrita em C, mas o typeshed tem dicas de tipos sobrecarregadas para ela, em builtins.pyi:

Primeiro, vamos olhar a sintaxe geral das sobrecargas. Esse acima é todo o código sobre sum que você encontrará no arquivo stub (.pyi). A implementação estará em um arquivo diferente. As reticências (...) não tem qualquer função além de cumprir a exigência sintática para um corpo de função, em vez usar de pass. Assim os arquivos .pyi são arquivos Python válidos.

Como mencionado na [arbitrary_arguments_sec], os dois sublinhados prefixando __iterable são a convenção da PEP 484 para argumentos apenas posicionais, que é checada pelo Mypy. Isso significa que você pode invocar sum(my_list), mas não sum(__iterable = my_list).

O checador de tipos tenta fazer a correspondência entre os argumentos dados com cada assinatura sobrecarregada, em ordem. A chamada sum(range(100), 1000) não casa com a primeira sobrecarga, pois aquela assinatura tem apenas um parâmetro. Mas casa com a segunda.

Você pode também usar @overload em um modulo Python (.py) normal, colocando as assinaturas sobrecarregadas logo antes da assinatura real da função e de sua implementação. O mysum.py: definição da função sum com assinaturaas sobrecarregadas mostra como sum apareceria anotada e implementada em um módulo Python.

1. Precisamos deste segundo TypeVar na segunda assinatura.

2. Essa assinatura é para o caso simples: sum(my_iterable). O tipo do resultado pode ser T—o tipo dos elementos que my_iterable produz—ou pode ser int, se o iterável for vazio, pois o valor default do parâmetro start é 0.

3. Quando start é dado, ele pode ser de qualquer tipo S, então o tipo do resultado é Union[T, S]. É por isso que precisamos de S. Se T fosse reutilizado aqui, então o tipo de start teria que ser do mesmo tipo dos elementos de Iterable[T].

4. A assinatura da implementação real da função não tem dicas de tipo.

São muitas linhas para anotar uma função de uma única linha. Sinto muito, mas pelo menos a função do exemplo não é foo.

Se quiser aprender sobre @overload lendo código, o typeshed tem centenas de exemplos. Quando escrevo esse capítulo, o arquivo stub do typeshed para as funções embutidas de Python tem 186 sobrecargas—mais que qualquer outro na biblioteca padrão.

As APIs convenientes e práticas que consideramos pythônicas são muitas vezes difíceis de anotar. Na próxima seção veremos um exemplo: são necessárias seis sobrecargas para anotar adequadamente a função embutida max, que é muito flexível nos parâmetros que aceita.

Algumas vezes os dicionários de Python são usados como registros, as chaves interpretadas como nomes de campos e os valores como valores dos campos de diferentes tipos. Considere, por exemplo, um registro descrevendo um livro, em JSON ou Python:

Antes de Python 3.8, não havia uma boa maneira de anotar um registro como esse, pois os tipos de mapeamento que vimos na [mapping_type_sec] limitam os valores a um mesmo tipo.

Aqui estão duas tentativas ruins de anotar um registro como o objeto JSON acima:

dict[str, Any]

As chaves são str mas os valores podem ser de qualquer tipo.

dict[str, str|int|list[str]]

Difícil de ler, e não preserva a relação entre os nomes dos campos e seus respectivos tipos: title deve ser uma str, ele não pode ser um int ou uma List[str].

A PEP 589—TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys (TypedDict: dicas de tipo para dicionários com um conjunto fixo de chaves_) resolve este problema. O books.py: a definição de BookDict mostra um TypedDict simples.

À primeira vista, typing.TypedDict pode parecer uma fábrica de classes de dados, similar a typing.NamedTuple—tratada no [ch_dataclass].

A similaridade sintática é enganosa. TypedDict é muito diferente. Ele existe apenas para orientar um checador de tipos, e não tem qualquer efeito durante a execução.

TypedDict fornece duas coisas:

• Uma sintaxe similar à de classe para anotar um dict com dicas de tipo para os valores de cada campo identificado por um chaves.

• Um construtor que informa que o checador de tipos deve esperar um dict com chaves e valores como especificados.

Durante a execução, um construtor de TypedDict como BookDict é um placebo: ele tem o mesmo efeito de uma chamada ao construtor de dict com os mesmos argumentos.

O fato de BookDict criar um dict simples também significa que:

• Os "campos" na definição da pseudoclasse não criam atributos de instância.

• Não é possível escrever inicializadores com valores default para os "campos".

• Não é permitido definir métodos.

Vamos explorar o comportamento de um BookDict durante a execução (no Usando um BookDict, mas não exatamente como planejado).

1. É possível invocar BookDict como um construtor de dict, com argumentos nomeados, ou passando um argumento dict—incluindo um literal dict.

2. Ops…​ esqueci que authors deve ser uma lista. Mas não há checagem de tipos estáticos durante a execução.

3. O resultado da chamada a BookDict é um dict simples…​

4. …​assim não é possível ler os campos usando a notação objeto.campo.

5. As dicas de tipo estão em BookDict.__annotations__, e não em pp.

Sem um checador de tipos, TypedDict é tão útil quanto comentários em um programa: pode ajudar a documentar o código, mas só isso. As fábricas de classes do [ch_dataclass], por outro lado, são úteis mesmo se você não usar um checador de tipos, porque durante a execução elas geram uma classe customizada que pode ser instanciada. Elas também fornecem vários métodos ou funções úteis, listadas na [dc_main_features_sec].

O demo_books.py: operações legais e ilegais em um BookDict cria um BookDict válido e tenta executar algumas operações com ele. A seguir, o Verificando os tipos em demo_books.py mostra como TypedDict permite que o Mypy encontre erros.

1. Lembre-se de adicionar o tipo devolvido, assim o Mypy não ignora a função.

2. Este é um BookDict válido: todas as chaves estão presentes, com valores do tipo correto.

3. O Mypy vai inferir o tipo de authors a partir da anotação na chave 'authors' em BookDict.

4. typing.TYPE_CHECKING só é True quando os tipos no programa estão sendo checados. Durante a execução ele é sempre falso.

5. O if anterior evita que reveal_type(authors) seja chamado durante a execução. reveal_type não é uma função de Python disponível durante a execução, mas sim um instrumento de depuração fornecido pelo Mypy. Por isso não há um import para ela. Veja sua saída no Verificando os tipos em demo_books.py.

6. As últimas três linhas da função demo são ilegais. Elas vão disparar mensagens de erro no Verificando os tipos em demo_books.py.

Verificando a tipagem em demo_books.py, do demo_books.py: operações legais e ilegais em um BookDict, obtemos o Verificando os tipos em demo_books.py.

1. Esta observação é o resultado de reveal_type(authors).

2. O tipo da variável authors foi inferido a partir do tipo da expressão que a inicializou, book['authors']. Você não pode atribuir uma str para uma variável do tipo List[str]. Checadores de tipo em geral não permitem que o tipo de uma variável mude.^[3]

3. Não é permitido atribuir a uma chave que não é parte da definição de BookDict.

4. Não se pode apagar uma chave que é parte da definição de BookDict.

Vejamos agora BookDict sendo usado em assinaturas de função, para checar o tipo em chamadas de função.

Imagine que você precisa gerar XML a partir de registros de livros como esse:

Se você estivesse escrevendo o código em MicroPython, para ser integrado a um pequeno microcontrolador, poderia escrever uma função parecida com o books.py: a função to_xml.^[4]

1. O principal objetivo do exemplo: usar BookDict em uma assinatura de função.

2. Se a coleção começa vazia, o Mypy não tem como inferir o tipo dos elementos. Por isso a anotação de tipo é necessária aqui.^[5]

3. O Mypy entende testes com isinstance, e trata value como uma list neste bloco.

4. Quando usei key == 'authors' como condição do if que guarda este bloco, o Mypy encontrou um erro nessa linha: "object" has no attribute "__iter__" ("object" não tem um atributo "__iter__" ), porque inferiu o tipo de value devolvido por book.items() como object, que não suporta o método __iter__ exigido pela expressão geradora. O teste com isinstance funciona porque garante que value é uma list neste bloco.

O books_any.py: a função from_json mostra uma função que interpreta uma str JSON e devolve um BookDict.

1. O tipo devolvido por json.loads() é Any.^[6]

2. Posso devolver whatever—de tipo Any—porque Any é consistente-com todos os tipos, incluindo o tipo declarado do valor devolvido, BookDict.

É muito importante de ter em mente segundo ponto do books_any.py: a função from_json: o Mypy não vai apontar qualquer problema neste código, mas durante a execução o valor em whatever pode não se adequar à estrutura de BookDict—pode até não ser um dict!

Se você rodar o Mypy com --disallow-any-expr, ele vai reclamar sobre as duas linhas no corpo de from_json:

As linhas 30 e 31 mencionadas no trecho acima são o corpo da função from_json. Podemos silenciar o erro de tipo acrescentando uma dica de tipo à inicialização da variável whatever, como no books.py: a função from_json com uma anotação de variável.

1. --disallow-any-expr não gera erros quando uma expressão de tipo Any é imediatamente atribuída a uma variável com uma dica de tipo.

2. Agora whatever é do tipo BookDict, o tipo declarado do valor devolvido.

A checagem de tipos estática é incapaz de prevenir erros cm código inerentemente dinâmico, como json.loads(), que cria objetos Python de tipos diferentes durante a execução. O demo_not_book.py: from_json devolve um BookDict inválido, e to_xml o aceita, o Relatório do Mypy para demo_not_book.py, reformatado por legibilidade e o Resultado da execução de demo_not_book.py demonstram isso.

1. Essa linha não produz um BookDict válido—veja o conteúdo de NOT_BOOK_JSON.

2. Vamos deixar o Mypy revelar alguns tipos.

3. Isso não deve causar problemas: print consegue lidar com object e com qualquer outro tipo.

4. BookDict não tem uma chave 'flavor', mas o fonte JSON tem…​o que acontecerá?

5. Lembre-se da assinatura: to_xml(book: BookDict) {rt-arrow} str:

6. Como será a saída em XML?

Agora checamos demo_not_book.py com o Mypy:

1. O tipo revelado é o tipo estático, não o conteúdo de not_book durante a execução.

2. De novo, este é o tipo estático de not_book['authors'], como definido em BookDict. Não o tipo durante a execução.

3. Este erro é para a linha print(not_book['flavor']): esta chave não existe no tipo estático.

Agora vamos executar demo_not_book.py, mostrando o resultado no Resultado da execução de demo_not_book.py.

1. Isso não é um BookDict de verdade.

2. O valor de not_book['flavor'].

3. to_xml recebe um argumento BookDict, mas não há qualquer checagem durante a execução: entra lixo, sai lixo.

O Resultado da execução de demo_not_book.py mostra que demo_not_book.py devolve bobagens, mas não há qualquer erro durante a execução. Usar um TypedDict ao tratar dados em formato JSON não resultou em uma tipagem segura.

Olhando o código de to_xml no books.py: a função to_xml do ponto de vista da tipagem pato, o argumento book deve fornecer um método .items() que devolve um iterável de tuplas na forma (chave, valor), onde:

• chave deve ter um método .upper()

• valor pode ser qualquer coisa.

A conclusão desta demonstração: quando estamos lidando com dados de estrutura dinâmica, tal como JSON ou XML, TypedDict não é, de forma alguma, um substituto para a validaçào de dados durante a execução. Para isso, use o pydantic.

TypedDict tem mais recursos, incluindo suporte a chaves opcionais, uma forma limitada de herança e uma sintaxe de declaração alternativa. Para saber mais sobre ele, estude a PEP 589—TypedDict: Type Hints for Dictionaries with a Fixed Set of Keys (TypedDict: dicas de tipo para dicionários com um conjunto fixo de chaves).

Vamos agora voltar nossa atenção para uma função que é melhor evitar, mas que algumas vezes é inevitável: typing.cast.

Nenhum sistema de tipos é perfeito, nem tampouco os checadores estáticos de tipo, as dicas de tipo no projeto typeshed ou as dicas de tipo em pacotes de terceiros, quando existem.

A função especial typing.cast() é uma forma de lidar com defeitos ou incorreções nas dicas de tipo em código que não podemos consertar. A documentação do Mypy 0.930 explica (tradução nossa):

Coerções são usadas para silenciar avisos espúrios do checador de tipos, e ajudam o checador quando ele não consegue entender o que está acontecendo.

Durante a execução, typing.cast não faz absolutamente nada. Esta é sua implementação:

A docstring diz: "Coage um valor para um tipo. Isto devolve o valor inalterado. Para o checador de tipos, isto sinaliza que o valor devolvido tem o tipo designado, mas na execução não fazemos nenhuma checagem (queremos que isto seja tão rápido quanto possível)".

A PEP 484 exige que os checadores de tipos "acreditem cegamente" em cast. A seção "Casts" (Coerções) da PEP 484 mostra um exemplo onde o checador precisa da orientação de cast:

A chamada next() na expressão geradora vai devolver o índice de um item str ou levantar StopIteration. Assim, find_first_str vai sempre devolver uma str se não for gerada uma exceção, e str é o tipo declarado do valor devolvido.

Mas se a última linha for apenas return a[index], o Mypy inferiria o tipo devolvido como object, porque o argumento a é declarado como list[object]. Então cast() é necessário para orientar o Mypy.^[7]

Aqui está outro exemplo com cast, desta vez para corrigir uma dica de tipo desatualizada na biblioteca padrão de Python. No [ex_tcp_mojifinder_main] do [ch_async], criei um objeto asyncio.Server, e queria obter o endereço onde o servidor está ouvindo (aceitando conexões). Escrevi esta linha de código:

Mas o Mypy informou o seguinte erro:

A dica de tipo para Server.sockets no typeshed, em maio de 2021, é válida para Python 3.6, onde o atributo sockets podia ser None. Mas no Python 3.7, sockets se tornou uma propriedade, com um getter que sempre devolve uma list—que pode ser vazia, se o servidor não tiver um socket. E desde o Python 3.8, esse getter devolve uma tuple (usada como uma sequência imutável).

Já que não posso consertar o typeshed nesse instante,^[8] acrescentei um cast, assim:

Usar cast nesse caso exigiu algumas horas para entender o problema e ler o código-fonte de asyncio, para encontrar o tipo correto para sockets: a classe TransportSocket do módulo não-documentado asyncio.trsock. Também precisei adicionar duas instruções import e mais uma linha de código para melhorar a legibilidade.^[9] Mas agora o código está mais seguro.

A leitora atenta pode ter notado que sockets[0] poderia gerar um IndexError se sockets estiver vazio. Entretanto, até onde entendo o asyncio, isso não pode acontecer no [ex_tcp_mojifinder_main] do [ch_async], pois no momento em que leio o atributo sockets, o server já está pronto para aceitar conexões , portanto o atributo não estará vazio. E, de qualquer forma, IndexError ocorre durante a execução. O Mypy não consegue localizar esse problema nem mesmo em um caso trivial como print([][0]).

Apesar de suas desvantagens, há usos válidos para cast. Eis algo que Guido van Rossum escreveu sobre isso:

O que está errado com uma ocasional chamada a cast() ou um comentário # type: ignore?^[10]

É insensato banir inteiramente o uso de cast, principalmente porque as alternativas para contornar esses problemas são piores:

• # type: ignore é menos informativo.^[11]

• Usar Any é contagioso: já que Any é consistente-com todos os tipos, seu abuso pode produzir efeitos em cascata através da inferência de tipo, minando a capacidade do checador de tipos para detectar erros em outras partes do código.

Claro, nem todos os contratempos de tipagem podem ser resolvidos com cast. Algumas vezes precisamos de # type: ignore, do Any aqui ou ali, ou mesmo deixar uma função sem dicas de tipo.

A seguir, vamos falar sobre o uso de anotações durante a execução.

Durante a importação, Python lê as dicas de tipo em funções, classes e módulos, e as armazena em atributos chamados __annotations__. Considere, por exemplo, a função clip no clipannot.py: a assinatura anotada da função clip.^[12]

As dicas de tipo são armazenadas em um dict no atributo __annotations__ da função:

A chave 'return' está mapeada para a dica do tipo devolvido após o símbolo {rt-arrow} no clipannot.py: a assinatura anotada da função clip.

Observe que as anotações são avaliadas pelo interpretador no momento da importação, ao mesmo tempo em que os valores default dos parâmetros são avaliados. Por isso os valores nas anotações são as classes Python str e int, e não as strings 'str' e 'int'. A avaliação das anotações no momento da importação é o padrão desde o Python 3.10, mas isso pode mudar se a PEP 563 ou a PEP 649 se tornarem o comportamento padrão.

No [ex_tombola_abc] do [ch_ifaces_prot_abc] definimos a ABC Tombola: uma interface para classes que funcionam como um recipiente para sorteio de bingo. A classe LottoBlower ([ex_lotto] do [ch_ifaces_prot_abc]) é uma implementação concreta. Vamos agora estudar uma versão genérica de LottoBlower, usada da forma que aparece no generic_lotto_demo.py: usando uma classe genérica de sorteio de bingo.

1. Para instanciar uma classe genérica, passamos a ela um parâmetro de tipo concreto, como int aqui.

2. O Mypy irá inferir corretamente que first é um int…​

3. …​ e que remain é uma tuple de inteiros.

Além disso, o Mypy aponta violações do tipo parametrizado com mensagens úteis, como ilustrado no generic_lotto_errors.py: erros apontados pelo Mypy.

1. Na instanciação de LottoBlower[int], o Mypy marca o float.

2. Na chamada .load('ABC'), o Mypy explica porque uma str não serve: str.__iter__ devolve um Iterator[str], mas LottoBlower[int] exige um Iterator[int].

O generic_lotto.py: uma classe genérica de sorteador de bingo é a implementação.

1. Declarações de classes genéricas muitas vezes usam herança múltipla, porque precisamos incluir a superclasse Generic para declarar os parâmetros de tipo formais—neste caso, T.

2. O argumento items em __init__ é do tipo Iterable[T], que se torna Iterable[int] quando uma instância é declarada como LottoBlower[int].

3. O método load é igualmente anotado.

4. O tipo do valor devolvido T agora se torna int em um LottoBlower[int].

5. Nenhuma variável de tipo aqui.

6. Por fim, T define o tipo dos itens na tuple devolvida.

Agora que vimos como implementar um classe genérica, vamos definir a terminologia para falar sobre tipos genéricos.

Já vimos o conceito de variância na [callable_variance_sec], aplicado a tipos genéricos Callable parametrizados. Aqui vamos expandir o conceito para abarcar tipos genéricos de coleções, usando uma analogia do "mundo real" para tornar mais concreto esse conceito abstrato.

Imagine uma cantina escolar que tenha como regra que apenas máquinas servindo sucos podem ser instaladas.^[15] Máquinas de bebida genéricas não são permitidas, pois podem servir refrigerantes, que foram banidos pela direção da escola.^[16]

A biblioteca padrão de Python 3.10 fornece alguns protocolos estáticos genéricos. Um deles é SupportsAbs, implementado assim no módulo typing:

T_co é declarado de acordo com a convenção de nomenclatura:

Graças a SupportsAbs, o Mypy considera válido o seguinte código, como visto no abs_demo.py: uso do protocolo genérico SupportsAbs.

1. Definir __abs__ torna Vector2d consistente-com SupportsAbs.

2. Parametrizar SupportsAbs com float assegura…​

3. …​que o Mypy aceite abs(v) como primeiro argumento para math.isclose.

4. Graças a @runtime_checkable na definição de SupportsAbs, essa é uma asserção válida durante a execução.

5. Todo o restante do código passa pelas checagens do Mypy e pelas asserções durante a execução.

6. O tipo int também é consistente-com SupportsAbs. De acordo com o typeshed, int.__abs__ devolve um int, o que é consistente-com o parametro de tipo float declarado na dica de tipo is_unit para o argumento v.

De forma similar, podemos escrever uma versão genérica do protocolo RandomPicker, apresentado no [ex_randompick_protocol] do [ch_ifaces_prot_abc], que foi definido com um único método pick devolvendo Any.

O generic_randompick.py: definição do RandomPicker genérico mostra como criar um RandomPicker genérico, covariante no tipo devolvido por pick.

1. Declara T_co como covariante.

2. Isso torna RandomPicker genérico, com um parâmetro de tipo formal covariante.

3. Usa T_co como tipo do valor devolvido.

O protocolo genérico RandomPicker pode ser covariante porque seu único parâmetro formal é usado em um tipo de saída.

Com isso, podemos dizer que temos mais um capítulo.

Começamos com um exemplo simples de uso de @overload, seguido por um exemplo mais complexo, que estudamos em detalhes: as assinaturas sobrecarregadas exigidas para anotar corretamente a função embutida max.

A seguir veio o tipo especial typing.TypedDict. Escolhi tratar dele aqui e não no [ch_dataclass], onde vimos typing.NamedTuple, porque TypedDict parece mas não é uma fábrica de classes; ele é meramente uma forma de acrescentar dicas de tipo a uma variável ou a um argumento que exige um dict com um conjunto específico de chaves do tipo string, e tipos específicos para cada chave—algo que acontece quando usamos um dict como registro, muitas vezes no contexto do tratamento de dados JSON. Aquela seção foi um pouco mais longa porque usar TypedDict pode levar a um falso sentimento de segurança, e eu queria mostrar como as checagens durante a execução e o tratamento de erros são inevitáveis quando tentamos criar registros estruturados estaticamente a partir de mapeamentos, que são dinâmicos por natureza.

Então falamos sobre typing.cast, uma função criada para nos permitir orientar o checador de tipos. É importante considerar cuidadosamente quando usar cast, porque seu uso excessivo atrapalha o checador de tipos.

O acesso a dicas de tipo durante a execução veio em seguida. O ponto principal era usar typing.get_type_hints em vez de ler o atributo __annotations__ diretamente. Entretanto, aquela função pode não ser confiável para algumas anotações, e vimos que os mantenedores de Python ainda estão discutindo uma forma de tornar as dicas de tipo usáveis durante a execução, e ao mesmo tempo reduzir seu impacto sobre o uso de CPU e memória.

A última seção foi sobre genéricos, começando com a classe genérica LottoBlower—que mais tarde aprendemos ser uma classe genérica invariante. Aquele exemplo foi seguido pelas definições de quatro termos básicos: tipo genérico, parâmetro de tipo formal, tipo parametrizado e parâmetro de tipo real.

Continuamos pelo grande tópico da variância, usando máquinas bebidas e latas de lixo para uma cantina como exemplos da "vida real" para tipos genéricos invariantes, covariantes e contravariantes. Então revisamos, formalizamos e aplicamos aqueles conceitos a exemplos na biblioteca padrão de Python.

Por fim, vimos como é definido um protocolo estático genérico, primeiro considerando o protocolo typing.SupportsAbs, e então aplicando a mesma ideia ao exemplo do RandomPicker, tornando-o mais rigoroso que o protocolo original do [ch_ifaces_prot_abc].

O sistema de tipagem estática de Python já era complexo quando foi originalmente projetado, e tem se tornado mais complexo a cada ano. A PEPs sobre dicas de tipo, com links nos títulos. PEPs com números marcados com * são importantes o suficiente para serem mencionadas no parágrafo de abertura da documentação de typing. Pontos de interrogação na coluna Python indica PEPs em discussão ou ainda não implementadas; "n/a" aparece em PEPs informacionais sem relação com uma versão específica de Python. Dados coletados em maio de 2021. lista todas as PEPs que encontrei até maio de 2021. Seria necessário um livro inteiro para cobrir tudo.

A documentação oficial de Python mal consegue acompanhar tudo aquilo, então a documentação do Mypy é uma referência essencial. Robust Python, de Patrick Viafore (O’Reilly), é o primeiro livro com um tratamento abrangente do sistema de tipagem estática de Python que conheço, publicado em agosto de 2021. Você pode estar lendo o segundo livro sobre o assunto nesse exato instante.

O tópico sutil da variância tem sua própria seção na PEP 484, e também é abordado na página Generics do Mypy, bem como em sua inestimável página Common Issues (Problemas Comuns).

A PEP 362—Function Signature Object (O objeto assinatura de função) vale a pena ler se você pretende usar o módulo inspect, que complementa a função typing.get_type_hints.

Se tiver interesse na história de Python, saiba que Guido van Rossum publicou Adding Optional Static Typing to Python (Acrescentando tipagem estática opcional ao Python).

Python 3 Types in the Wild: A Tale of Two Type Systems (Os tipos de Python 3 na natureza: um conto de dois sistemas de tipo) é um artigo científico de Ingkarat Rak-amnouykit e outros, do Rensselaer Polytechnic Institute e do IBM TJ Watson Research Center. O artigo avalia o uso de dicas de tipo em projetos de código aberto no GitHub, mostrando que a maioria dos projetos não as usa, e também que a maioria dos projetos que têm dicas de tipo aparentemente não usa um checador de tipos. Achei particularmente interessante a discussão das semânticas diferentes do Mypy e do pytype do Google, onde os autores concluem que eles são "essencialmente dois sistemas de tipos diferentes."

Dois artigos fundamentais sobre tipagem gradual são Pluggable Type Systems (Sistemas de tipo conectáveis), de Gilad Bracha, e Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages (Tipagem Estática Quando Possível, Tipagem Dinâmica Quando Necessário: O Fim da Guerra Fria Entre Linguagens de Programação), de Eric Meijer e Peter Drayton.^[17]

Aprendi muito lendo as partes relevantes de alguns livros sobre outras linguagens que implementam algumas das mesmas ideias:

• Atomic Kotlin, de Bruce Eckel e Svetlana Isakova (Mindview)

• Effective Java, 3rd ed.,, de Joshua Bloch (Addison-Wesley)

• Programming with Types: TypeScript Examples, de Vlad Riscutia (Manning)

• Programming TypeScript, de Boris Cherny (O’Reilly)

• The Dart Programming Language de Gilad Bracha (Addison-Wesley).^[18]

Para algumas visões críticas sobre os sistemas de tipagem, recomendo os posts de Victor Youdaiken Bad ideas in type theory (Ideias ruins em teoria dos tipos) e Types considered harmful II (Tipos considerados nocivos II).

Por fim, me surpreendi ao encontrar Generics Considered Harmful (Genéricos Considerados Nocivos), de Ken Arnold, um desenvolvedor principal de Java desde o início, bem como co-autor das primeiras quatro edições do livro oficial The Java Programming Language (Addison-Wesley)—com James Gosling, o principal criador de Java.

Infelizmente, as críticas de Arnold também se aplicam ao sistema de tipagem estática de Python. Quando leio as muitas regras e casos especiais das PEPs de tipagem, sou constantemente lembrado dessa passagem do post de Arnold:

O que nos traz ao problema que sempre cito para o C++: a "exceção de enésima ordem à regra de exceção".

É mais ou menos assim: "Você pode fazer x, exceto no caso y, a menos que y faça z, caso em que você pode se…​"

Felizmente, Python tem uma vantagem crítica sobre o Java e o C++: um sistema de tipagem opcional. Podemos silenciar os checadores de tipos e omitir as dicas de tipo quando se tornam muito inconvenientes.