Por que o with existe

O problema do recurso deixado aberto

Muitos recursos de um programa seguem o mesmo ritual: você abre, usa e fecha. Um arquivo é o exemplo mais comum, mas a mesma lógica vale para conexões de rede, bloqueios entre threads e transações de banco de dados. O perigo mora no fechar. Se você esquece de fechar um arquivo, ou se uma exceção interrompe o programa antes da linha que fecha, o recurso fica preso. Arquivos abertos demais esgotam um limite do sistema; locks não liberados travam outras threads.

# Frágil: se processar() lançar uma excecao,
# a linha arquivo.close() nunca roda e o arquivo fica aberto.
arquivo = open("dados.txt")
dados = arquivo.read()
processar(dados)      # e se isto falhar?
arquivo.close()       # esta linha pode nunca ser alcancada

Sem proteção, uma exceção no meio impede o fechamento do arquivo.

O trecho acima parece correto, e funciona enquanto tudo dá certo. O problema aparece no dia ruim: se processar levantar uma exceção, o Python abandona o fluxo normal e pula direto para o tratamento de erro mais próximo, sem passar pela linha do close. O arquivo fica aberto até o coletor de lixo eventualmente cuidar dele, o que é imprevisível. Confiar na sorte para fechar recursos é uma fonte clássica de bugs que só aparecem sob carga.

Da solução manual para o with

A solução tradicional é o try com finally: você coloca o uso do recurso no try e o fechamento no finally, que roda sempre, com erro ou sem. Funciona, mas é verboso e fácil de esquecer. O with foi criado exatamente para embutir esse padrão. Quando você escreve with open(...) as arquivo, o Python garante que o arquivo será fechado ao sair do bloco, não importa se a saída foi normal ou por uma exceção. É o mesmo finally, embutido e legível.

# Robusto e pythônico: o arquivo fecha ao sair do bloco,
# mesmo que processar() lance uma excecao.
with open("dados.txt") as arquivo:
    dados = arquivo.read()
    processar(dados)
# aqui o arquivo ja esta fechado, garantido

O with garante o fechamento na saída do bloco, com erro ou sem erro.

A diferença não é só estética. O with transforma uma promessa que depende da disciplina do programador em uma garantia da própria linguagem. Por isso a recomendação é clara: sempre que um objeto oferecer suporte a with, use with. E quando você criar seus próprios recursos, arquivos temporários, conexões, bloqueios, vale torná-los compatíveis com with, para que quem os use ganhe a mesma garantia de limpeza. As próximas aulas mostram exatamente como fazer isso.

Onde o with já aparece no seu dia a dia

Você já usa context managers mesmo sem ter reparado. Abrir arquivo com with open é o caso mais comum. Mas a biblioteca padrão usa o mesmo mecanismo em vários lugares: um Lock de threads é usado com with para garantir a liberação; conexões de banco de dados oferecem with para confirmar ou desfazer uma transação; e há utilitários prontos no módulo contextlib. Reconhecer o padrão ajuda a entender o que aquele with está de fato garantindo em cada caso.