Sobre A Tipagem De Python É Correto Afirmar Que:

O que realmente acontece com os tipos no Python

A tipagem do Python é dinâmica, fraca e duck typing. Isso significa que os tipos são verificados em tempo de execução, não há obrigatoriedade de declaração explícita, e um objeto é identificado pelo que ele sabe fazer, não pelo seu nome de classe. Muita gente confunde esses conceitos na hora de estudar para prova ou revisar para entrevista. É correto afirmar que a tipagem em Python é dinâmica, fortemente tipada e baseada em duck typing. Dinâmica porque não exigimos declarar o tipo na variável. Forte porque o interpretador impõe regras de tipo e não faz coerção automática permissiva como PHP ou JavaScript fazem. Duck typing porque "se anda como um pato e faz quack como um pato, então é um pato." OPython não tem variáveis com tipo atrelado. Ele tem nomes que apontam para objetos, e esses objetos carregam seu próprio tipo internamente. Isso é uma distinção importante que quase todo mundo erra.

Como isso se comporta na prática

Já vi código rodando tranquilo até um método de banco de dados chamar uma string esperando um inteiro. O erro só aparecia em produção porque o type check nunca existiu. A minha solução foi simples: passei a usar type hints com mypy no CI. O custo inicial foi uns dez minutos de configuração por projeto, mas desde então erros desse tipo caíram de quase um por semana para praticamente zero. Um exemplo concreto que muita gente não leva a sério no começo:

O interpretador permite a reatribuição. Mas quando você tenta operar tipos incompatíveis, ele dispara. Isso é tipagem forte na prática. Linguagens fracas deixariam essa conta acontecer de algum jeito estranho, às vezes truncando valores, às vezes convertendo silenciosamente. Esse é um equívoco frequente. Duck typing não quer dizer que tipos não importam. Quer dizer que o que importa é a interface, não a herança. Se você passar um objeto que tem método fechar() e ler(), uma função que espera um arquivo vai funcionar. Pode ser um arquivo real, pode ser uma string, pode ser uma conexão de rede. Desde que os métodos existam, o Python não reclama.

Isso é poderoso. Mas também é onde as coisas quebram sem aviso prévio. Um colega meu já perdeu meia tarde debugando porque uma função recebia um dicionário quando esperava um objeto com atributos, e o AttributeError só aparecia em um caminho específico da lógica que raramente era executado.

Tipos opcionais com type hints

A partir do Python 3.5, introduziram-se os type hints. Eles são exatamente isso: dicas. O interpretador não os aplica. O código roda normalmente sem eles. Mas ferramentas como mypy, pyright e o próprio IDE usam essas anotações para detectar inconsistências antes da execução. O uso mais comum é com o módulo typing:

Isso não altera o comportamento em runtime. Mas se alguém chamar processa(123), o mypy já avisa antes de qualquer teste ser escrito. Uma delas é mutable default argument. Funções com listas ou dicionários como padrão de parâmetro compartilham o mesmo objeto entre chamadas. O código abaixo parece inocente mas carrega um bug clássico: A correção é usar None como padrão e criar a lista dentro da função. Isso não tem relação direta com tipagem, mas é consequência direta de como o Python lida com objetos e escopo.

Projetos grandes sem type hints viram uma caixa de surpresas. A inferência de tipos fica impossível para qualquer ferramenta externa acompanhar, e refatorações viram roleta russa. O Python 3.12 melhorou a inferência interna, mas ainda depende muito de boas práticas manuais. Alternativas como Pydantic oferecem validação em runtime usando type hints como contrato. É útil quando você recebe dados de APIs externas e precisa garantir que o payload bate com o esperado antes de processar. A desvantagem é sobrecarga de performance em hot paths críticos, embora para a maioria dos serviços web esse custo seja irrelevante.

Resumo direto

A tipagem do Python é dinâmica, forte e baseada em duck typing. Nomes apontam para objetos tipados, não o contrário. Type hints existem como documentação executável, não como imposição do interpretador. Erros de tipo aparecem em runtime quando operações incompatíveis se encontram. A maior armadilha não é o sistema de tipos em si, mas a falsa sensação de segurança que a flexibilidade traz.