Filosofia do Python

Publicação original: http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html
Autor original: Guido van Rossum

As próximas entradas nesse blog aprofundarão detalhes da história do Python. Entretanto, antes que eu o faça, gostaria de apresentar a linha filosófica que me ajudou a tomar decisões enquanto projetava e implementava Python.

Primeiro, Python fora originalmente concebida como um projeto experimental de uma pessoa - não havia orçamento oficial e eu desejava resultados rápidos, em parte porque assim poderia convencer a gerência a suportar o projeto (tarefa a qual obtive sucesso moderado). Isso me levou a algumas regras que economizam tempo:

• Tome emprestadas idéias de qualquer lugar, desde que elas façam sentido.
• "As coisas devem ser as mais simples possíveis, mas não mais simples." - Einstein
• Faça uma única coisa bem (A "filosofia Unix").
• Não se preocupe muito sobre desempenho -- planeje otimizar depois, quando necessário.
• Não reme contra a maré -- siga o fluxo.
• Não tente ser perfeccionista. "Bom o suficiente" frequentemente é isso.
• (Portanto) Tudo bem economizar às vezes, principalmente se puder fazer corretamente mais tarde.

Outros princípios não tinham intenção de economizar tempo. Às vezes ocorria justamente o oposto:

• A implementação de Python não deve estar atada a uma plataforma em particular. Tudo bem se determinada funcionalidade não estiver disponível sempre, mas o núcleo da linguagem deve funcionar em todo lugar.
• Não incomode o usuário com detalhes que a máquina pode cuidar (nem sempre segui essa regra e algumas consequências desastrosas estão descritas em seções posteriores).
• Suporte e encorage código independente de plataforma, mas não remova o acesso a propriedades ou capacidades da plataforma (isso é um contraste gritante em relação a Java).
• Um sistema grande e complexo deveria ter vários níveis de extensibilidade. Esse fato maximiza a oportunidade para que usuários, sofisticados ou não, se ajudem.
• Erros não devem ser fatais. Ou seja, códigos dos usuários devem ser capazes de se recuperar de condições de erro, desde que a máquina virtual permaneça funcional.
• Por outro lado, erros não devem passar desapercebidos (esses dois últimos itens levaram ao uso de exceções durante a implementação).
• Nunca um bug no código do usuário deve levar a comportamentos indefinidos no interpretador de Python; um core dump nunca é falha do usuário.

Finalmente, eu tive várias idéias sobre um bom projeto de linguagem, que fora vastamente enraizado em mim pelo grupo de ABC onde tive minha primeira experiência real com projeto e implementação de linguagem. Essas idéias são difíceis de expressar, já que basicamente são sobre elegância, simplicidade e legibilidade.

Embora eu vá discutir mais sobre influência da ABC posteriormente, gostaria de mencionar uma regra específica sobre legibilidade: caracteres de pontuação deveriam ser usados conservadoramente, alinhados com seu uso comum em inglês ou álgebra. Exceções são feitas quando uma notação particular já é tradicional em linguagens de programação, como "x*y" para multiplicação, "a[i]" para indexação de vetores, ou "x.foo" para seleção de atributo, mas Python não usa "$" para indicar variáveis, nem "!" para indicar operações com efeitos colaterais.

Tim Peters, um usuário de Python de longa data e que eventualmente tornou-se um dos mais prolíficos e tenazes desenvolvedores, capturou meu princípio de design não documentado no que ele chama "O Zen de Python."
Cito aqui em sua totalidade:

• Belo é melhor que feio.
• Explícito é melhor que implícito.
• Simples é melhor que complexo.
• Complexo é melhor que complicado.
• Plano é melhor que aninhado.
• Esparso é melhor que denso.
• Legibilidade conta.
• Casos especiais não são especiais o suficiente para violar as regras.
• Embora praticidade vença pureza.
• Erros não devem passar silenciosamente.
• A não ser que sejam explicitamente silenciados.
• Em caso de ambiguidade, resista à tentação de adivinhar.
• Deve haver um - e somente um - jeito óbvio de fazer.
• Embora tal jeito não seja tão óbvio no à primeira vista a não ser que você seja holandês.
• Agora é melhor que nunca.
• Embora nunca é frequentemente melhor que exatamente agora.
• Se a implementação é difícil de explicar, a ideia é ruim.
• Se a implementação é fácil de explicar, talvez a ideia seja boa.
• Espaços de nomes são uma ideia estupenda - vamos fazer mais deles!

Embora minha experiência com ABC tenha fortemente influenciado Python, o grupo de ABC tinha alguns princípios de design que eram radicalmente diferentes dos princípios de Python. Em muitas maneiras, Python é uma fuga consciente destes:

• O grupo ABC se empenhava pela perfeição. Por exemplo, eles usavam algoritmos para estrutura de dados baseadas em árvores que haviam sido demonstrados ótimos para entradas assintoticamente grandes (mas não eram tão boas para entradas pequenas).
• O grupo ABC queria isolar o usuário, tão completamente quanto possível, do "grande e mal mundo dos computadores." Não apenas não deveria haver limites para faixa de valores de números, comprimento de cadeias de caracteres ou tamanho de coleções (a não ser quantidade de memória disponível), bem como os usuários não deveriam ser solicitados a lidar com arquivos, "salvamento" ou outros programas. ABC deveria ser a única ferramenta da qual eles precisariam. Esse desejo levou o grupo ABC a criar um ambiente de edição completo, único à ABC (havia uma forma de escapar do ambiente ABC, claro, mas foi sobretudo uma idéia posterior e não acessível diretamente a partir da linguagem.)
• O grupo ABC assumia que os usuários não tinham experiência prévia com computadores (ou desejavam esquecê-la). Portanto, terminologia alternativa, mais amigável para iniciantes, foi introduzida em vez do jargão padrão de programação. Por exemplo, procedimentos eram chamados "how-tos" (NT: como fazer) e variáveis, "locations" (NT: locais).
• O grupo ABC projetou ABC sem uma linha evolucionária em mente e sem esperar participação do usuário no projeto da linguagem. ABC foi criada como um sistema fechado, tão sem falhas quanto seus projetistas poderiam torná-la. Usuários não eram encorajados a ver os detalhes internos da implementação. Embora tenha se falado em abrir parte da implementação para usuários avançados em estágios posteriores do projeto, isso nunca foi feito.

De certa forma, a filosofia de projeto que usei quando criei Python é provavelmente uma das principais razões para seu sucesso estrondoso. Em vez de almejar pela perfeição, os primeiros usuários consideraram que ela era "boa o suficiente" para seus propósitos. À medida que a base de usuários cresceu, sugestões de melhorias foram gradualmente incorporadas à linguagem. Como veremos em seções futuras, muitas dessas melhorias involveram mudanças substanciais e reconstrução de partes importantes da linguagem. Ainda hoje, Python continua a evoluir.