Tipos em Python têm um problema de expectativas

Artigo original ↗ Discussão no Hacker News ↗

As anotações de tipo em Python estão sendo questionadas por criarem um “descompasso de expectativas”: parecem um sistema de tipos embutido, mas não fornecem garantias sem ferramentas externas como mypy ou pyright e sem integrá-las ao editor, CI ou pipeline de implantação. Os comentários discutem se o Python deveria oferecer imposição mais rígida e opcional, semelhante ao TypeScript ou Rust, compartilham estratégias práticas e dificuldades ao aplicar tipagem gradualmente em bases de código legadas grandes e apontam bibliotecas como Pydantic ou verificações em tempo de execução no estilo Sorbet como soluções parciais. As opiniões divergem sobre o valor mais amplo da tipagem estática em uma linguagem dinâmica, com alguns citando melhor tooling, segurança em refatorações e detecção mais precoce de bugs, e outros argumentando que ela adiciona verbosidade sem evidência clara de menos defeitos.

Descompasso de Expectativas: Anotações de Tipo vs. Impor Validação

  • Muitos veem um descompasso: as anotações de tipo estão na biblioteca padrão e na sintaxe, mas o CPython as ignora em tempo de execução e nenhum verificador é executado por padrão.
  • Alguns argumentam que o Python nunca iria incluir um verificador de tipos completo; ferramentas externas (mypy, pyright) são a solução prática, análoga aos compiladores do TypeScript.
  • Outros gostariam de um modo “strict” ou de wrapper que execute um verificador de tipos antes da execução, especialmente para implantações (por exemplo, falhar rápido na inicialização do Kubernetes em vez de em tempo de execução).

Versionamento, Erros e Ferramentas

  • A sintaxe de tipagem mais nova (por exemplo, dict[int, int]) em versões antigas do Python produz erros de tempo de execução confusos (“type object is not subscriptable”).
  • from __future__ import annotations não resolve isso completamente; há bugs de casos extremos e comportamento obscuro.
  • IDEs (VS Code, PyCharm) geralmente usam anotações de tipo para autocompletar, embora a cobertura seja incompleta e muitas vezes dependa de pacotes stub.

Bases de Código Legadas com Tipagem Gradual

  • Adotar tipagem em bases de código grandes e sem tipagem é relatado como doloroso:
    • Rodar mypy no repositório inteiro gera uma enxurrada de erros impossível de administrar, então as verificações de CI muitas vezes são ignoradas.
    • Abordagens com “seed file” (listar manualmente arquivos para verificar tipos) adicionam atrito e churn no CI.
  • Estratégias sugeridas: usar a configuração do mypy por módulo, desativar o acompanhamento de imports inicialmente, tipar primeiro os módulos folha e aumentar a rigidez ao longo do tempo.
  • Hooks de mypy no pre-commit são vistos como lentos demais e disruptivos; preferem-se verificações apenas no CI.

Expressividade e Uso em Tempo de Execução

  • Python pode modelar comportamentos complexos: unions, overloads, TypeVars e tipos recursivos, mas muitas vezes com padrões verbosos (@overload, grandes conjuntos de stubs) e limites práticos.
  • Alguns usam anotações em tempo de execução (por exemplo, Pydantic, carregadores customizados de JSON/dataclass, bibliotecas de strict-typing), mas isso é mais lento e não é oficialmente o objetivo do design.

Debate Tipagem vs. Produtividade

  • Um grupo afirma que tipagem estática em Python adiciona boilerplate, alonga o desenvolvimento e pode aumentar o número de bugs por funcionalidade; eles argumentam que a maioria dos bugs é comportamental e exige testes de qualquer forma, e que a tipagem do Python não é forte o suficiente para monólitos enormes.
  • Outros discordam fortemente, citando bases de código Python tipadas em larga escala onde as anotações melhoraram a compreensão, o suporte da IDE, refatorações e detectaram bugs reais cedo.
  • Alegações empíricas sobre taxa de bugs e eficácia da tipagem são contestadas; o thread não apresenta consenso claro nem evidência definitiva.

Documentação vs. Anotações Inline

  • Alguns preferem docstrings ricas (ou dicas baseadas em comentários) em vez da sintaxe de tipos inline por legibilidade, querendo “código puro” com tipos como metadados secundários.
  • Outros argumentam que a melhor prática é usar ambos: anotações inline para ferramentas e compreensão rápida, mais docstrings para semântica de nível mais alto.