[[afterword]]
[postface]
[role="afterword"]
== Posfácio

[quote, Alan Runyan, co-fundador do Plone]
____
Python é uma linguagem para programação consensual entre adultos.
____

A((("Python", "community support for"))) 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` footnote:[NT: termos com maiúsculas no início de cada palavra de uma expressão composta.],
do `snake_case` footnote:[NT: termos com hífens separando palavras de uma expressão composta],
e `joinedwords` footnote:[NT: composição direta de palavras] 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 ((("python-tulip list"))) a python-tulip, intitulada https://fpy.li/a-1["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 https://docs.python.org/pt-br/3/library/asyncio-eventloop.html#executor[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)"))) 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((("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((("Python Users Group (PUG)"))) 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((("Python", "further reading on"))) 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 https://fpy.li/a-3["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: https://fpy.li/a-4["Transforming Code into Beautiful, Idiomatic Python" (_Transformando Código em Belo Python Idiomático_)] (EN).

A thread https://fpy.li/a-5["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 https://fpy.li/a-6[`pep8`], que verifica código Python quanto à aderência ao PEP 8. Para verificar o código deste livro usei o https://fpy.li/a-7[`flake8`], que inclui o `pep8`, https://fpy.li/a-8[`pyflakes`], e o https://fpy.li/a-9[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 https://fpy.li/a-10[_Google Python Style Guide_ ("Guia de Estilo Python do Google")] e o
https://fpy.li/a-11[_Pocoo Styleguide_ ("Guia de Estilo Pocoo")], do mesmo grupo que nos deu o Flake, o Sphinx, a Jinja 2 e outras ótimas bibliotecas Python.

https://fpy.li/a-12[_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 https://fpy.li/a-13["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 https://fpy.li/a-14[sistema oficial de documentação] do MongoDB e de muitos outros projetos).

Martijn Faassen enfrenta a questão diretamente em https://fpy.li/a-15["What is Pythonic?" (_O que é pythônico?_)]
Na python-list há uma thread com https://fpy.li/a-16[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 é https://fpy.li/a-17["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 https://fpy.li/pep3099[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 https://fpy.li/a-18["Python Essays" (_Ensaios sobre Python_)] lista vários textos do próprio Guido.
