O Modelo de Execução do Python

Todas as outras páginas desta seção - variáveis, fluxo de controle, funções, módulos - baseiam-se em um modelo subjacente de como o Python realmente executa o código.

Esse modelo é mais simples do que parece de fora: nomes são vinculados a objetos dentro de namespaces, e quase tudo que você faz em Python é alguma variação de criar um objeto e vincular um nome a ele.

Esta página é o modelo mental por trás de Variáveis, Tipos e Tipagem Dinâmica, Fluxo de Controle, Funções, Args e Escopo e Módulos, Imports e Pacotes.

Uma vez que você entenda, as regras de escopo, o cache de importação e a armadilha de argumento padrão mutável param de parecer peculiaridades separadas e começam a parecer o mesmo mecanismo aparecendo em lugares diferentes.

Resumo

• A execução de código Python é o ato repetido de vincular nomes a objetos dentro de namespaces - atribuição, def, class e import são todas especializações dessa única operação.
• Por que Importa: Assim que você vê nomes e objetos como coisas separadas conectadas por vínculos, as regras de escopo, o estado mutável compartilhado e o cache de importação param de ser casos especiais e se tornam consequências previsíveis de um único mecanismo.
• Conceitos-Chave: vinculação de nome, namespace, escopo (LEGB), identidade do objeto, cache de módulo.
• Quando Usar: Para raciocinar sobre por que duas variáveis são mutadas juntas, por que uma função lê uma variável externa mas não pode reatribuí-la sem nonlocal, ou por que editar um arquivo de módulo em tempo de execução não afeta uma cópia já importada.
• Limitações / Trade-offs: A flexibilidade da vinculação dinâmica de nomes custa algumas garantias estáticas - o tipo de destino de um nome pode mudar em tempo de execução, e ferramentas só podem aproximar o que uma linguagem totalmente estática verifica gratuitamente.
• Tópicos Relacionados: semântica de referência e mutabilidade, escopo de função e closures, o sistema de importação, o modelo de objeto do CPython.

Fundamentos

A mudança de pensamento mais útil sobre Python é parar de chamar x = 5 de "armazenar 5 em x" e começar a chamar de "vincular o nome x a um objeto inteiro 5".

O objeto existe independentemente, com seu próprio tipo, valor e identidade; o nome é apenas um rótulo apontando para ele, armazenado em um namespace.

Um namespace é, concretamente, um dicionário que mapeia nomes (strings) a objetos - globals() e locals() dão uma olhada direta em dois deles.

x = [1, 2, 3]
print(globals()["x"] is x)  # True - o namespace do módulo é realmente um dict

Atribuição (x = ...), def, class e import se reduzem à mesma primitiva: construir (ou localizar) um objeto, e então vincular um nome a ele no namespace atual.

É por isso que uma função e um módulo ambos têm atributos que você pode inspecionar - um objeto de função tem um __name__, um __doc__, um __defaults__; um objeto de módulo tem quaisquer nomes que seu código de nível superior vinculou.

Uma analogia útil é um sistema de arquivamento: objetos são as pastas físicas armazenadas, e nomes são notas adesivas apontando para elas - mover uma nota adesiva (reatribuir um nome) nunca toca na pasta, mas escrever dentro de uma pasta (mutar um objeto) é visível para todas as notas adesivas que apontam para ela.

Mecanismos e Interações

Todo namespace existe dentro de um escopo específico, e o Python resolve um nome nu buscando escopos em uma ordem fixa: Local, Enclosing (Envolvente), Global, Built-in (Embutido) - LEGB.

Cada chamada de função cria um novo namespace local (um frame), que é por que chamadas recursivas não sobrescrevem as variáveis umas das outras, mesmo que compartilhem o mesmo objeto de código.

nonlocal e global existem porque ler um nome busca para fora através de LEGB automaticamente, mas atribuir a um nome tem como padrão criá-lo localmente - essas duas palavras-chave dizem ao Python "pule a criação local, reatribua o nome que já existe mais adiante".

def make_counter():
    count = 0
    def increment():
        nonlocal count      # sem isso, count += 1 levanta UnboundLocalError
        count += 1
        return count
    return increment
 
tick = make_counter()
print(tick(), tick())  # 1 2 - o estado vive no frame envolvente, não globalmente

O sistema import adiciona um mecanismo de cache sobre o mesmo modelo: o primeiro import mymodule executa o código de nível superior desse arquivo exatamente uma vez, constrói um objeto de módulo a partir do namespace resultante e o armazena em sys.modules; qualquer import mymodule posterior em qualquer lugar do processo apenas busca esse objeto em cache em vez de reexecutar o arquivo.

Este único fato explica duas surpresas comuns de uma vez: editar o código-fonte de um módulo em tempo de execução não tem efeito até que o processo seja reiniciado ou o módulo seja explicitamente recarregado, e importar um módulo com efeitos colaterais (como abrir uma conexão no nível superior) só incorre nesse custo uma vez, não importa quantos arquivos o importem.

Valores de argumento padrão interagem com este modelo de uma forma que engana quase todo mundo uma vez: def f(items=[]) avalia [] uma única vez, quando a instrução def é executada, e armazena esse único objeto de lista em __defaults__ da função - cada chamada que omite items compartilha esse mesmo objeto, que é por que mutá-lo dentro da função vaza estado entre chamadas.

Considerações Avançadas e Aplicações

CPython compila o código-fonte em bytecode (visualizável através do módulo dis) antes que uma máquina virtual o execute frame a frame, que é por que Python é geralmente chamado de linguagem interpretada, mesmo que exista uma etapa de compilação real.

Durante a maior parte da história do CPython, o Global Interpreter Lock (GIL) serializou a execução de bytecode entre threads em um único processo, o que significa que código multi-thread limitado por CPU raramente roda mais rápido que código single-thread - uma consequência direta de como o modelo de objeto de contagem de referências gerencia a segurança da memória.

Python 3.13 introduziu uma build free-threaded experimental (PEP 703) que pode rodar sem o GIL, e Python 3.14 continua a estabilizá-la como um modo de build oficial (embora ainda opcional) - uma evolução genuína deste modelo de execução, não apenas um botão de ajuste.

A coleta de lixo segue a mesma história de objeto e referência: CPython usa principalmente contagem de referência (um objeto é liberado no instante em que sua contagem atinge zero), apoiado por um coletor cíclico que periodicamente varre ciclos de referência que a contagem sozinha não consegue capturar, como dois objetos que apontam um para o outro.

Entender namespaces como dicionários também explica por que dir(), vars() e getattr() funcionam uniformemente em módulos, instâncias e classes - eles estão apenas inspecionando ou consultando um objeto baseado em namespace em vez de três recursos de linguagem não relacionados.

Equívocos Comuns

• "Variáveis Python são como variáveis C - slots de armazenamento tipados." Um nome não tem tipo próprio; o objeto ao qual ele está vinculado tem um tipo, e o mesmo nome pode ser reatribuído a um tipo de objeto completamente diferente a qualquer momento.
• "Atribuição copia o valor." Atribuição vincula um nome ao objeto existente; dois nomes podem apontar para o mesmo objeto mutável, que é por que y = x; y.append(1) também muda o que x vê para objetos mutáveis.
• "Todo import reexecuta o código do módulo." Apenas o primeiro import por processo faz isso; todo import subsequente do mesmo nome de módulo retorna o objeto em cache de sys.modules.
• "Uma função aninhada pode ler e escrever qualquer variável envolvente livremente." A leitura percorre LEGB automaticamente, mas atribuir dentro de uma função aninhada cria um novo nome local por padrão, a menos que nonlocal diga o contrário.
• "Argumentos padrão mutáveis são reavaliados em cada chamada." A expressão padrão é executada uma vez, no momento do def, e o objeto resultante é reutilizado em cada chamada que omite esse argumento.

FAQs

Relacionados

• Variáveis, Tipos e Tipagem Dinâmica - semântica de referência e identidade de objeto em profundidade
• Fluxo de Controle - como construtos de ramificação e loop executam dentro deste mesmo modelo
• Funções, Args e Escopo - escopo LEGB e vinculação de argumentos na prática
• Módulos, Imports e Pacotes - o cache de importação e namespaces de pacotes de perto
• Fundamentos do Python - um tour prático da sintaxe que este modelo sustenta

Versões da Stack: Esta página foi escrita para Python 3.14 (estável) e Python 3.13 (manutenção), incluindo as notas sobre a build free-threaded introduzidas em 3.13 e estabilizadas ainda mais em 3.14.