Python é uma linguagem para programação consensual entre adultos.
co-fundador do Plone
A definição sagaz do Alan expressa uma das melhores qualidades de Python: ele sai da frente e deixa você fazer o que for preciso. Isso também significa que a linguagem não dá ferramentas para restringir o que outros podem fazer com seu código e com os objetos que ele cria.
Aos 30, Python segue ganhando popularidade.
Mas, claro, não é perfeito.
Entre minhas maiores irritações está o uso inconsistente do CamelCase [1],
do snake_case [2],
e joinedwords [3] na biblioteca padrão.
Mas a definição da linguagem e a biblioteca padrão são apenas uma parte de um ecossistema.
A comunidade de usuários e colaboradores é a melhor parte do ecossistema Python.
Aqui está um exemplo da força da comunidade: quando estava escrevendo sobre asyncio na primeira edição, ficava frustrado porque a API tem muitas funções, dezenas das quais são corrotinas, e era preciso invocar corrotinas com yield from—agora com await—mas você não pode fazer isso com funções regulares. Isso estava documentado nas páginas do asyncio, mas por vezes era necessário ler alguns parágrafos para descobrir se uma função específica era uma corrotina. Então mandei uma mensagem para a python-tulip, intitulada "Proposal: make coroutines stand out in the asyncio docs" (Proposta: destacar as corrotinas na documentação do asyncio). Victor Stinner, um dos desenvolvedores principais do asyncio; Andrew Svetlov, principal autor do aiohttp; Ben Darnell, desenvolvedor principal do Tornado; e Glyph Lefkowitz, inventor do Twisted, se juntaram à conversa. Darnell sugeriu uma solução, Alexander Shorin explicou como implementá-la no Sphinx, e Stinner acrescentou a configuração e as marcações necessárias. Em menos de 12 horas após eu ter relatado o problema, toda a documentação online do asyncio estava atualizada com as tags coroutine que vemos hoje.
Isso não se passou em um clube exclusivo. Qualquer pessoa pode se juntar à lista python-tulip, e eu havia escrito ali apenas algumas vezes antes de enviar aquela proposta. Essa história mostra uma comunidade realmente aberta a novas ideias e a novos membros. Guido van Rossum costumava frequentar a python-tulip, e muitas vezes respondia perguntas básicas.
Outro exemplo de abertura: a Python Software Foundation (PSF) tem trabalhado para aumentar a diversidade na comunidade Python. Alguns resultados encorajadores já apareceram. A diretoria para 2013–2014 da PSF viu as primeiras diretoras eleitas: Jessica McKellar e Lynn Root. Em 2015, Diana Clarke presidiu a PyCon North America em Montreal, onde cerca de um terço dos palestrantes foram mulheres. A PyLadies se tornou um movimento verdadeiramente global, e me orgulha que tenhamos tantas seções da PyLadies no Brasil.
Se você é um pythonista mas ainda não se envolveu com a comunidade, encorajo você a fazê-lo. Procure a PyLadies ou um Grupo de Usuários Python na sua vizinhança. Se nenhum existir, crie um. Python está em todo lugar, então você não ficará sozinho. Viaje para eventos, se puder. Junte-se também a eventos online. Durante a pandemia de Covid-19, aprendi muito nos "encontros no hall" das conferências online. Venha a uma conferência da PythonBrasil—temos a presença de palestrantes estrangeiros há anos. Encontrar outros pythonistas traz benefícios reais além do compartilhamento de conhecimento. Como empregos reais e amizades reais.
Sei que não conseguiria escrever esse livro sem a ajuda dos muitos amigos que fiz na communidade Python ao longo desses anos.
Meu pai, Jairo Ramalho, costumava dizer que "Só erra quem trabalha", um ótimo conselho para não se deixar paralisar pelo medo de cometer erros. Eu certamente cometi minha cota de erros durante a escrita desse livro. Os revisores, editores e leitores das versões iniciais pegaram muitos deles. Horas após o pré-lançamento da primeira edição, um leitor já estava enviando relatórios de erros ortográficos na página de erratas do livro. Outros leitores contribuiram com mais relatórios, e amigos me contataram diretamente com sugestões e correções. Os revisores da O’Reilly irão achar outros erros durante o processo de produção, que começará assim que eu conseguir parar de escrever. Assumo toda a responsabilidade e me desculpo por qualquer erro ou trechos com escrita truncada que restarem.
Estou muito feliz em concluir essa segunda edição, com erros e tudo, e estou muito agredecido a todos que me ajudaram pelo caminho.
Espero encontrar você logo em algum evento. Por favor, venha dizer olá se nos cruzarmos por aí!
Leitura complementar
Vou encerrar com referências sobre o que significa ser "pythônico”—a principal questão que tentei apresentar neste livro.
Brandon Rhodes é um fantático professor de Python, e sua palestra "A Python Æsthetic: Beauty and Why I Python" (Uma Estética Python: o Belo e Porque Eu 'Pythono') (EN) é linda, começando pelo uso do caractere Unicode U+00C6 (LATIN CAPITAL LETTER AE) no título (em inglês). Outro professor maravilhoso, Raymond Hettinger, falou sobre a beleza no Python na PyCon US 2013: "Transforming Code into Beautiful, Idiomatic Python" (Transformando Código em Belo Python Idiomático) (EN).
A thread "Evolution of Style Guides" (A Evolução dos Guias de Estilo) (EN), iniciada por Ian Lee no Python-ideas, vale a leitura. Lee é o mantenedor do pacote pep8, que verifica código Python quanto à aderência ao PEP 8. Para verificar o código deste livro usei o flake8, que inclui o pep8, pyflakes, e o McCabe complexity plug-in (plug-in de complexidade McCabe ou complexidade ciclomática), de Ned Batchelder.
Além do PEP 8, outros influentes guias de estilo são o Google Python Style Guide ("Guia de Estilo Python do Google") e o Pocoo Styleguide ("Guia de Estilo Pocoo"), do mesmo grupo que nos deu o Flake, o Sphinx, a Jinja 2 e outras ótimas bibliotecas Python.
The Hitchhiker’s Guide to Python! ("O Guia do Mochileiro Python") é um esforço coletivo sobre a escrita de código pythônico. Seu contribuidor mais prolífico é Kenneth Reitz, um herói da comunidade devido a seu maravilhoso e pythônico pacote requests. David Goodger apresentou um tutorial na PyCon US 2008 intitulado "Code Like a Pythonista: Idiomatic Python" (Programe como um Pythonista: Python Idiomático). Se impressas, as notas do tutorial tem 30 páginas. Goodger criou tanto reStructuredText quanto docutils—as bases do Sphinx, o excelente sistema de documentação de Python (que, por sinal, também é o sistema oficial de documentação do MongoDB e de muitos outros projetos).
Martijn Faassen enfrenta a questão diretamente em "What is Pythonic?" (O que é pythônico?) Na python-list há uma thread com o mesmo título. O post de Martijn é de 2005, e a thread de 2003, mas o ideal pythônico não mudou muito—e aliás, nem a própria linguagem mudou tanto. Uma ótima thread com "pythônico" no título é "Pythonic way to sum n-th list element?" (A forma pythônica de somar os "n" elementos de uma lista), que citei extensivamente no [sequence_hacking_soapbox].
A PEP 3099 — Things that will Not Change in Python 3000 (PEP 3099 — Coisas que não vão mudar no Python 3000) explica porque muitas coisas são como são, mesmo após uma revisão profunda como foi Python 3. Por muito tempo, Python 3 foi apelidado Python 3000, mas acabou chegando alguns séculos adiantado—para o desespero de alguns. A PEP 3099 foi escrita por Georg Brandl, compilando muitas opiniões expressas pelo BDFL Guido van Rossum. A página "Python Essays" (Ensaios sobre Python) lista vários textos do próprio Guido.