Antes de escrever a primeira linha de código, vale a pena entender de onde veio a linguagem que você está prestes a aprender. Python não surgiu do nada — ele é o resultado de escolhas deliberadas de design feitas por uma pessoa que queria, acima de tudo, que programar fosse uma atividade agradável.
A Origem: um projeto de natal
Em dezembro de 1989, um programador holandês chamado Guido van Rossum estava de férias no Natal e decidiu ocupar o tempo livre criando uma nova linguagem de programação. Ele trabalhava no Centro de Matemática e Informática (CWI) em Amsterdã e tinha experiência com uma linguagem chamada ABC — elegante, mas fechada e difícil de estender.
Guido queria algo diferente: uma linguagem legível como inglês, fácil de aprender, mas poderosa o suficiente para uso profissional. O nome Python não veio da serpente — veio do grupo de comédia britânico Monty Python's Flying Circus, do qual Guido era fã.
A primeira versão pública, Python 0.9.0, foi lançada em fevereiro de 1991. Já nessa versão estavam presentes conceitos que permanecem até hoje: funções, tratamento de exceções, e os tipos centrais como listas e dicionários.
A Evolução da Linguagem
Python 1.x (1994) A versão 1.0 chegou em 1994, trazendo ferramentas funcionais como lambda, map, filter e reduce. A linguagem começa a ganhar usuários fora do meio acadêmico.
Python 2.x (2000) Python 2.0 introduziu as compreensões de lista (list comprehensions) e o coletor de lixo automático. Por anos foi a versão dominante — mas carregava problemas de design, principalmente no tratamento de texto.
Python 3.x (2008) Python 3.0 foi lançado com uma premissa radical: corrigir os erros do passado mesmo quebrando compatibilidade com o Python 2. O tratamento de texto foi refeito do zero, a divisão inteira foi corrigida, e a linguagem ficou mais consistente. Em 1º de janeiro de 2020, Python 2 chegou ao fim de vida. Hoje, Python significa Python 3.
O ciclo virou anual: sai uma versão nova em outubro de cada ano, cada uma com cerca de cinco anos de vida — um ano e meio recebendo correção de bugs e o restante só correção de segurança. A 3.14 é a mais recente, e a 3.9 e anteriores já saíram de suporte. Antes de começar um projeto, vale conferir em devguide.python.org/versions qual ainda recebe correção — rodar uma versão fora de suporte é acumular falha conhecida e sem conserto.
Por que Python é tão popular?
- Sintaxe limpa. Indentação obrigatória força legibilidade — um programa Python bem escrito parece prosa técnica.
- Versatilidade. A mesma linguagem serve para automação, APIs web, análise de dados e machine learning.
- Ecossistema imenso. O repositório PyPI contém mais de 500 mil pacotes.
- Comunidade ativa. Documentação excelente, fóruns e suporte crescente em português.
A Filosofia do Python: o Zen
Python tem uma filosofia oficial. Você pode lê-la a qualquer momento — a saída vem em inglês, como Tim Peters escreveu:
python3 -c "import this"
Alguns princípios centrais:
Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Legibilidade conta.
Se a implementação é difícil de explicar, é uma má ideia.
Instalação
Windows
- Acesse https://www.python.org/downloads/
- Baixe a versão mais recente estável
- No instalador, marque "Add Python to PATH"
- Verifique no Prompt de Comando:
python --version
macOS
brew install python
python3 --version
Linux (Ubuntu/Debian)
sudo apt update
sudo apt install python3 python3-pip
python3 --version
O Interpretador Interativo (REPL)
Abra o terminal e digite python3. Você verá algo assim — a versão e a data do build variam conforme a sua instalação:
Python 3.12.3 (main, Apr 9 2024, 08:09:14)
>>>
Experimente:
>>> print("Olá, mundo!")
Olá, mundo!
>>> 2 + 2
4
>>> nome = "Ricardo"
>>> print(f"Bem-vindo, {nome}!")
Bem-vindo, Ricardo!
Para sair: exit(), ou Ctrl+D no Linux e no macOS e Ctrl+Z seguido de Enter no Windows.
Se o terminal responder command not found, o problema provavelmente não é a instalação: o comando nem sempre se chama python3. No Windows o instalador registra python e o lançador py; em várias instalações Linux e dentro de um ambiente virtual existe só python, sem o 3. Tente o outro nome antes de reinstalar — daqui em diante, onde estiver escrito python3, use o que responder na sua máquina.
Primeiro Programa em Arquivo
Salve o seguinte como ola_mundo.py:
# Meu primeiro programa em Python
nome = input("Qual é o seu nome? ")
print(f"Olá, {nome}! Bem-vindo ao mundo do Python.")
Execute no terminal:
python3 ola_mundo.py
A história importa aqui por um motivo prático: quase tudo o que parece arbitrário na linguagem deixa de parecer quando se sabe de onde veio. A indentação obrigatória não é preciosismo estético, é a aposta de que código se lê mais vezes do que se escreve. A ruptura do Python 3 custou doze anos de transição justamente porque texto e bytes precisavam deixar de ser coisas distintas, e não havia como consertar isso sem quebrar o que existia. E o ciclo anual de versões, com prazo de validade declarado para cada uma, é o que permite que a linguagem continue mudando sem repetir aquele trauma.
Do lado prático, o interpretador está instalado, o comando responde — com um nome ou com o outro — e o REPL já devolveu resultado. É pouco código até aqui, e de propósito: nada do que vem depois se aprende lendo, e sim com o terminal aberto e respondendo.
Fontes e leituras recomendadas
- Documentação oficial do Python — https://docs.python.org/3/
- História do Python (Guido van Rossum) — https://python-history.blogspot.com/
- PEP 20 — The Zen of Python — https://peps.python.org/pep-0020/
- Python Package Index (PyPI) — https://pypi.org/
- VS Code para Python — https://code.visualstudio.com/docs/languages/python
- MATTHES, Eric. Python Crash Course. 3. ed. No Starch Press, 2023.
- LUTZ, Mark. Learning Python. 5. ed. O'Reilly Media, 2013.
Exercícios
Exercício 1
O artigo diz que o Python 3 "corrigiu os erros do passado mesmo quebrando compatibilidade" e cita o tratamento de texto. Por que justamente texto foi a mudança que exigiu quebrar tudo, em vez de ser resolvida com uma função nova?
Ver resposta
✓ Resposta: Porque no Python 2 o tipo str era uma sequência de bytes, e texto Unicode morava num tipo separado, unicode. Pior: os dois se misturavam em silêncio. Comparar, concatenar ou interpolar um com o outro disparava uma conversão automática usando ASCII como codificação presumida, e o programa só explodia com UnicodeDecodeError quando aparecia o primeiro caractere acentuado — muitas vezes em produção, meses depois, com dado vindo de um usuário. O resultado prático é que o mesmo programa funcionava ou falhava dependendo do conteúdo dos dados, o que é o pior tipo de defeito que existe. Não dava para corrigir com uma função nova porque o problema não era falta de ferramenta: era o significado do tipo mais usado da linguagem estar errado. Toda biblioteca, toda assinatura de função, todo código que lia arquivo ou soquete assumia a semântica antiga. No Python 3, str passou a ser texto Unicode e os bytes ganharam o tipo bytes, sem conversão implícita entre eles — se você tentar juntar os dois, o erro acontece na hora, não quando o dado for inconveniente. É essa troca, de erro tardio e imprevisível por erro imediato, que justificou doze anos de transição.
Exercício 2
O artigo apresenta o Zen do Python com import this e traduz alguns princípios. Um colega argumenta que "Explícito é melhor que implícito" é conselho vago, do tipo que cabe em qualquer linguagem. Aponte uma decisão concreta de projeto do Python que só se explica por esse princípio.
Ver resposta
✓ Resposta: A mais evidente é o self explícito nos métodos. Em quase toda linguagem orientada a objetos o receptor é implícito — o this de Java, C# ou JavaScript simplesmente existe dentro do método, sem aparecer na assinatura. Em Python, quem escreve def cumprimentar(self, nome): declara o receptor como primeiro parâmetro, e é por isso que obj.metodo(x) e Classe.metodo(obj, x) são a mesma chamada escrita de dois jeitos. Guido defendeu essa escolha publicamente mais de uma vez, e o argumento é exatamente o do Zen: não há regra oculta de resolução de nome, o que está no escopo do método é o que está escrito. Um segundo exemplo, do mesmo princípio: no Python 3 não existe conversão implícita entre str e bytes, nem entre número e texto — "3" + 3 levanta TypeError em vez de adivinhar se o certo era "33" ou 6, como faz o JavaScript. Um terceiro: a importação nomeada. Módulo nenhum despeja nomes no escopo global sem que alguém escreva from x import y. Nos três casos a linguagem prefere obrigar você a escrever uma palavra a mais hoje a deixar quem for ler o código daqui a um ano ter de adivinhar.
Exercício 3
Você segue a instalação do artigo e digita python3 --version no Prompt de Comando do Windows. O terminal responde que o comando não foi encontrado, ou então abre a Microsoft Store. O que está acontecendo, e qual é a sequência para diagnosticar?
Ver resposta
✓ Resposta: São dois problemas diferentes com sintomas parecidos. O primeiro é de nome: o instalador oficial do Windows não cria nada chamado python3. Ele registra python e o lançador py, que é o caminho mais confiável ali, porque sabe conviver com várias versões instaladas — py -0 lista todas e py -3.12 escolhe uma. Os comandos com sufixo 3 são convenção de Linux e macOS, onde precisavam conviver com o Python 2 do sistema. O segundo é o atalho da Microsoft Store: o Windows traz um app execution alias para python.exe que, quando não há Python instalado, abre a loja em vez de dar erro. Isso engana porque parece que o comando existe. Se ele aparecer depois de você ter instalado, é sinal de que o alias está na frente da instalação real no PATH — desligue em Configurações, em "Aliases de execução de aplicativo". A sequência de diagnóstico é: tentar py --version, depois python --version; se algum responder, o problema era só o nome. Se nenhum responder, rodar where python para ver o que o PATH está encontrando. E a causa mais comum de tudo isso é a caixa "Add Python to PATH", que vem desmarcada no instalador e que o artigo pede para marcar — sem ela, o Python fica instalado e invisível para o terminal.
Exercício 4
O artigo mostra o REPL como primeiro contato e depois o arquivo ola_mundo.py. Qual é a diferença real entre os dois modos, e em que situação o REPL engana quem está aprendendo?
Ver resposta
✓ Resposta: A diferença que importa é que o REPL imprime o valor de cada expressão automaticamente, e o script não. Digitar 2 + 2 no prompt mostra 4; a mesma linha sozinha dentro de um arquivo calcula a soma, descarta o resultado e não mostra nada. É por isso que o iniciante escreve o script, roda, não vê saída nenhuma e conclui que "não funcionou" — quando na verdade funcionou e ninguém pediu para imprimir. No arquivo, o que aparece na tela é só o que passa por print(). Há uma segunda armadilha, mais sutil: o REPL mantém estado entre os comandos. Uma variável definida há dez minutos continua lá, e um import feito no começo da sessão continua valendo. Isso faz um trecho quebrado parecer correto, porque ele depende de algo que só existe naquela sessão e que não está no arquivo. Ao copiar código do REPL para um .py, é comum descobrir que falta o import. A regra prática: o REPL serve para experimentar — testar o que um método devolve, conferir um comportamento, ler um help() — e o arquivo serve para construir, porque é reproduzível, versionável e roda igual na máquina de outra pessoa.
Exercício 5
O artigo conta que Python 2 chegou ao fim de vida em 1º de janeiro de 2020, depois de mais de uma década de convivência com o Python 3. Que lição essa transição deixou, e como ela aparece no jeito como a linguagem é versionada hoje?
Ver resposta
✓ Resposta: A lição é que quebra de compatibilidade sem caminho de migração paralisa um ecossistema inteiro. O Python 3 saiu em 2008, e por anos o conselho honesto para quem começava um projeto continuou sendo "use o 2", porque as bibliotecas de que se dependia ainda não tinham migrado — e elas não migravam porque seus usuários estavam no 2. Foi um impasse circular que só se desfez com ferramenta de compatibilidade, um prazo final anunciado com anos de antecedência e adiado uma vez, e muito trabalho voluntário. O efeito nas decisões de hoje é direto e visível em três pontos. Primeiro, não há Python 4 no horizonte, e quando o assunto aparece a resposta pública é que não haverá outra ruptura desse tipo. Segundo, mudança incompatível passou a ter rito: a funcionalidade é marcada como obsoleta, emite DeprecationWarning por pelo menos dois ciclos e só então é removida — foi assim com o distutils e com o lote de módulos antigos da biblioteca padrão. Terceiro, o calendário anual com fim de vida publicado troca a pergunta "vai quebrar algum dia?" por "quando exatamente", que é uma pergunta que cabe no planejamento. Na prática, para quem escreve código hoje: rodar a suíte de testes com python -W error::DeprecationWarning antecipa a quebra para o momento em que ela ainda é um aviso, e não uma falha em produção.