Recentemente o time da Anaconda anunciou o Pyscript uma nova tentativa de integrar Python no desenvolvimento de Frontends web. Python é famosa por ser uma linguagem multipropósitos - em contraste com linguagens como R e Matlab, que são linguagens pensadas para usos mais fechados. No entanto, os 'multipropósitos' do Python são normalmente distantes do usuário final não-técnico. APIs, pipelines de Machine Learning, Sistemas de Suporte, Análises de Dados, Python faz tudo isso bem.

No entanto Python não possui uma presença forte no lado do cliente. Projetos como o Kivy, o Beeware e o Brython tentam lutar essa batalha há alguns anos com níveis diferentes de sucesso. Escrevendo essa matéria, descobri inclusive que o Beeware está contratando!

O Pyscript é o novo projeto na área. Construído em cima do Pyodide, ele consegue fazer uma forma nova de integração com o browser. O projeto Beeware, por exemplo, tinha o projeto Batavia - que também mirava rodar Python no browser. O problema de rodar coisas no browser é que, historicamente, browsers só rodam JavaScript. Como contornar isso?

O Monopólio do JS

Moeda comemorativa que ganhei em 2016, por colaborar com o projeto Batavia

Bem, linguagens de programação "grandes" como Python, JavaScript, C, PHP, Java, Pascal e etc possuem uma propriedade interessante conhecida como Turing-Equivalência. Informalmente isso significa que qualquer uma dessas linguagens pode ser usada para rodar código feito em qualquer outra. Ou seja, eu posso escrever um interpretador de Javascript em C, ou um compilador de C em PHP, ou um interpretador de Java em Python. Como consequência dessa propriedade, podemos escrever um interpretador de Python em JavaScript. Ora, se eu consigo escrever um interpretador Python em JavaScript e os navegadores sabem rodar JavaScript, eu consigo então rodar Python no navegador. Era esse o objetivo do projeto Batavia - escrever um interpretador Python em JavaScript.

Apesar dessa estratégia garantidamente funcionar, ela tem seus pontos negativos. Notadamente, no processamento normal do Python, o interpretador converte nossos códigos para um bytecode que é interpretado pela máquina virtual do Python que por sua vez é implementada em C. Com um projeto como o Batavia, a máquina virtual é feita em JavaScript. A execução dessa máquina virtual vai envolver passar o código agora pelo pipeline de processamento do JavaScript em si, que também vai ter a sua própria máquina virtual. Ou seja, o processamento vai ter aproximadamente o dobro de passos.

Quase dois anos atrás, em 30 de maio de 2020 o projeto Batavia foi pausado num anúncio que é basicamente uma previsão do futuro, que viria ser o Pyscript:

... [T]he approach that is being used by Batavia needs to be reconsidered.
In particular, the emergence of WASM as a viable target for web development
opens many options for Python on the web that weren't previously possible.

Tradução minha:

A abordagem que está sendo usada pelo Batavia precisa ser reconsiderada.
Em particular, o surgimento do WASM como algo viável em desenvolvimento
web abre muitas opções para Python na web que não eram previamente possíveis

WASM?

Na mensagem de fechamento do Batavia, fica claro que o criador do projeto estava vislumbrando um futuro - o WASM, também conhecido como WebAssembly. Nossos computadores não entendem nossas linguagens de programação de verdade. Se você tentar conversar com a sua CPU em C, Python, JavaScript ou qualquer uma dessas linguagens, você vai ter como resposta o silêncio eterno de um punhado de silício.

A única forma de conversar com uma CPU é através da sua própria linguagem de montagem, conhecida como "Assembly". Por exemplo na página 87 desse PDF - "3.3.6 Arithmetic" - você pode ver as instruções matemáticas que minha CPU suporta. Note que ela não tem uma instrução para, por exemplo, elevar um número a uma potência arbitrária, como 7 elevado à 3. Se eu quiser fazer isso, vou precisar montar uma série de instruções para fazer isso.

Independente da linguagem de programação ser puramente interpretada, compilada ou uma combinação dos dois - Python e JS são normalmente chamadas de "interpretadas" mas, na verdade, elas possuem compiladores dentro de seus interpretadores - no fim do dia você precisa que seu código vire Assembly de alguma forma. Sem isso, você não faz nada.

Então, em 2017, surgiu o que é conhecido como WebAssembly, o WASM. Basicamente, a ideia é definir uma série de instruções que uma máquina virtual embutida nos navegadores vai aceitar. Se todos os navegadores embutirem essa máquina virtual dentro de si, algo interessante pode acontecer! Ao invés de nós construirmos código Python que vai ser convertido no Assembly entendido por uma CPU Intel ou AMD, nós convertemos em Assembly que vai ser entendido por uma máquina virtual Web Assembly! O resultado - Python que roda no navegador. Ou Rust, ou Go, ou qualquer outra linguagem, na verdade. Basta que a gente comece ter como alvo do processo de compilação uma máquina virtual WASM!

Entra o Pyodide

Para essa "mágica" acontecer nós precisamos fazer com que código na linguagem de entrada (Python, no caso) seja de alguma forma traduzido para WASM. O Pyodide faz exatamente isso.

Nesse link você vai ter um console Python completo. Rodando no seu navegador. Não tem um servidor em algum lugar servindo esse console. O que está acontecendo aí é que o seu navegador está recebendo instruções na máquina virtual web assembly que ele tem embutida dentro dele!

Pyscript - Pyodide + HTML

E finalmente temos a nova promessa de Python nos navegadores. Somando o poder do Pyodide com uma forma fácil de rodar código in-line, o pyscript tem potencial para tornar o uso de Python no front realmente viável.

Observe como nós estamos lidando com o novo passo de um processo histórico - o pyscript é a realização do que o projeto Batavia já vislumbrava dois anos atrás, quando parou suas atividades. O próprio projeto Batavia já vinha de anos de experimentação com o tema. Eu, particularmente, conheci o projeto em 2016.

O Futuro

O Pyscript vem da Anaconda, uma empresa que possui gente muito boa e recursos para de fato fazer a diferença. A performance ainda é uma questão. Python através de WASM é mais lento que Python comum. Porém, Python no Frontend é uma área que interessa a muita gente. Por exemplo, o gigantesco mercado de Data Science com todo o investimento que tem recebido possui muito a ganhar com soluções Python verdadeiramente "full stack". A Anaconda é em si uma empresa que atua nesse mercado.

Além disso, a linguagem Python em si - como discuti nas Notas do Bidu - possui planos de melhoria que vão fatalmente avançar na performance do Pyodide também.

No fim das contas, além de ficar feliz em ver Python - uma linguagem que gosto bastante - ganhar um novo caminho no importantíssimo mundo do desenvolvimento frontend web, eu fico também feliz com a possibilidade de novas linguagens abrirem caminho nesse espaço. Independente das minhas opiniões sobre JavaScript, o monopólio tecnológico que ela tem sobre o frontend web tem se mostrado, na minha opinião, nocivo.

Os porquês disso são assuntos para um outro post, hoje vou me limitar a dizer que vejo valor no conflito de ideias de tecnologias diferentes no mesmo espaço. Que forma será que o ecossistema de computação numérica do Python teria hoje sem a competição que teve por vários anos com R? Será que uma competição saudável não vai nos permitir a focar melhor nossos esforços em ideias que entregam valor de maneira duradoura ao invés de criar frameworks inteiros para JS toda vez que ficamos tristes com algo?

O futuro vai nos mostrar se pyscript se estabelecerá ou será mais um passo rumo ao objetivo, seja como for, eu acho uma baita ideia e que realmente tem potencial.

Saiba Mais

O @rochacbruno gravou um vídeo explorando o pyscript e seus exemplos:

https://www.youtube.com/watch?v=Mj47se4FOPk

Veja também a documentação oficial

Como toda tecnologia nova, é legal ler e assistir sobre, mas o mais legal é colocar a mão na massa :D

Ah, aquela moeda bonita que ganhei por colaborar com o Batavia foi graças à uma Python Brasil! Na Python Brasil de 2016, Russel, o criador do projeto, esteve no Brasil e nós tivemos a oportunidade de colaborar com o projeto junto dele, ao vivo e presencialmente. Essas são as chamadas "Sprints" que acontecem nos eventos da comunidade. Você pode acompanhar as novidades sobre a Python Brasil 2022 no site oficial. Será em Manaus, de 17 a 23 de Outubro

Um dia, essa semana, acordei me sentindo mal. Uma mistura estranha de enjôo e dor de cabeça. Refleti sobre o dia anterior, não havia consumido nada de estranho. Tentei trabalhar, não consegui. Declarei 'dia de saúde', como a gente chama na minha empresa quando não consegue trabalhar por estar mal.

Sentei na minha mesa e fiquei refletindo - o que fazer? Bem, tomei um remédio para ajudar os sintomas e comecei a pensar nos meus dias. Ando lotado de trabalho vindo de diversas fontes. Tanto do meu emprego full-time como de outros projetos paralelos que tenho, mentorias, aulas que dou, consultorias, aulas que faço, etc. Olhei para minha agenda, meu Todoist, minha mesa, minha gaveta - tudo estava bagunçado.

A sensação era de sufocamento. Onde eu olhava, não conseguia ver o que deveria fazer. A quantidade de informação era absurda e separar sinal de ruído era praticamente impossível. Então eu parei e comecei a organizar as coisas.

Minha principal ferramenta? Dizer "não" para coisas que não faziam mais sentido, responder aquele e-mail que me propunha pegar 4 tarefas dizendo que eu poderia - naquele prazo - pegar no máximo uma ou duas, jogar fora aqueles 3 cabos USB-C que já não funcionavam, mas estavam na primeira gaveta do meu armário, cancelar aquele MBA aleatório que eu tava fazendo e não estava conseguindo aproveitar, alinhar expectativas com projetos que assumi, limpar armários.

Enfim, encontrar espaço para respirar. Nos cronogramas, nos e-mails, nas gavetas, no dia-a-dia. Nos nossos dias e na nossa era, temos muitas possibilidades. Podemos fazer muito mais do que qualquer geração jamais sonhou. Quer aprender um pouco de Polonês? Bem, você pode instalar um app de idiomas, navegar pela Cracóvia no Street View, ler jornais poloneses on-line e até conversar com poloneses, tudo isso em pouco mais de uma ou duas horas na internet.

Informação, como diz o título de um livro de James Gleick, virou uma inundação (The Information: A History, a Theory, a Flood). Com tantas possibilidades, é fácil querermos fazer muito e nos esquecermos do que é mais importante, do que tem mais impacto, do que queremos fazer de fato. E nós, pessoas da computação, somos particularmente vulneráveis a isso, simplesmente pelo número gigantesco de possibilidades naturais da nossa área, nossa exposição gigante à tecnologia e os diversos incentivos do mercado para fazer mais coisas.

Minha dica? Evitem precisar parar de maneira meio forçada para pensar em como andam seus dias e o que vocês tem feito. No atrito diário, é fácil perder noção - eu mesmo costumava fazer revisões semanais todas às sextas e parei de fazer nas últimas muitas semanas, simplesmente porque deixei outras coisas ocuparem o lugar. Infelizmente, perdemos o fio da meada de vez em quando, acontece. Por mais vigilante que a gente fique, uma hora podemos nos ver numa bola de neve. O importante, para mim, é fazer as pazes com isso, não me sentir culpado pela eventual bagunça, limpar e pensar em como evitar que ela apareça de novo.

O nosso cérebro, afinal, vai arrumar tempo para descansar. Quer a gente queira, quer não. Quer a gente planeje por isso, quer não.

A linguagem SQL possui algumas funções úteis para fazer análises estatísticas. Normalmente você encontrará funções como sum, average, max e min que retornam a soma, média, valor máximo e mínimo de uma determinada coluna, respectivamente. Essas funções são chamadas de "agregações", pois elas retornam um único dado com base em uma série de dados, ou seja, elas agregam esses dados.

É difícil falar de SQL em geral pois cada distribuidor faz o seu próprio "jeitinho" de SQL, formalmente conhecidos como dialetos. O SQL usado pelo Google BigQuery, por exemplo, possui um ecossistema riquíssimo de funções estatísticas prontas. O ponto desse post, porém, é mais amplo:

É mais eficiente em termos de tempo de execução utilizar dessas funções prontas do SQL ou fazer as análises em seja lá qual linguagem de programação a gente tá usando?

Um Exemplo em Python

O código abaixo foi recortado para exibir apenas as partes mais importantes.

Considere duas funções diferentes para somar o total de valores de uma coluna chamada "Milliseconds". A primeira, faz uma query para listar todos os resultados da tabela, passa por todos os resultados um a um e soma o valor da coluna numa variável:

def sum_manual():
    query = select(track)
    result = engine.execute(query)

    sum_ = 0
    for row in result:
        sum_ += row.Milliseconds
    return sum_

A segunda função, por outro lado, envia para o servidor SQL uma query pedindo pelo resultado de sum. Ou seja, quem vai fazer o trabalho é o servidor SQL e não nosso código:

def sum_sql():
    query = select(func.sum(track.columns["Milliseconds"]))
    result = engine.execute(query)
    return result.scalar()

Com a função mágica %timeit do Jupyter e do ipython, podemos comparar os resultados:

%timeit sum_manual()
2.07 s ± 13.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%timeit sum_sql()
39.1 ms ± 418 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

Ou seja, somar manualmente levou, em média, 2.07s. Somar através do SQL, 39.1ms. A função que utiliza de SQL foi quase 53 vezes mais rápida do que a manual.

Em geral, esse é o comportamento que veremos - utilizar do servidor de SQL para fazer essas operações é mais rápido. A análise aqui foi bastante limitada - o servidor SQL era simplesmente um SQLite que estava rodando na minha máquina local - e ainda assim conseguimos ver diferenças.

Você talvez já tenha ouvido falar sobre coisas como "análise de complexidade de algoritmos", "notação grande-O (big-O)", "análise assintótica" e outras coisas do tipo. É possível utilizar de ferramentas assim para fazer uma análise mais detalhada dessas duas funções. Mais tarde, nessa mesma semana, publico uma análise do tipo. Se inscreva na newsletter do blog para ficar sabendo das novidades :D

O texto abaixo foi escrito no formulário do SBC sobre "Por que você escolheu um curso de Computação", da Comissão de Educação. A ideia era dar uma mensagem de motivação para futuros alunos em um curso superior de Computação

Eu acho importante alinharmos as expectativas. Um curso de graduação em computação assim como toda graduação é um possível primeiro passo em uma carreira. Não é a sua carreira toda e nem é o único primeiro passo possível.

Um curso de graduação (...) não é sua carreira toda

Dito isso, eu ouço muitas críticas de colegas com coisas do tipo "nossa, a faculdade não me ensinou nada que a empresa X me cobra no trabalho". Bem, eu não acho que isso seja um problema tão grave quanto parece.

Veja, uma graduação não deveria ficar correndo atrás do que há de mais chamativo ou mais na moda na indústria. Como alguém que trabalha na indústria desde antes de entrar na graduação eu te falo - essas coisas vão e vem. Mas o que você vai aprender numa graduação sólida em computação vai te permitir absorver mais rápido seja lá qual for a novidade que a empresa X, Y ou Z tem usado.

Tome desenvolvimento mobile, por exemplo, as técnicas usadas para programar Android em 2014 são consideradas antigas hoje. Porém, de Java ao Kotlin, de Objective-C ao Swift - no caso de iOS - os fundamentos de orientação à objetos e demais paradigmas, algoritmos, bancos de dados, engenharia e arquitetura de software continuam bastante válidos. Se nosso foco fosse em seja lá o que há de mais chamativo em um determinado momento, não montaríamos essa base.

Conhecimentos teóricos podem ser mais chatos, mas eles costumam ser mais duradouros do que correr atrás de tecnologias mais aplicadas

Existe muito a ser falado sobre onde mora o equilíbrio entre conhecimentos teóricos mais 'puros' e conhecimentos práticos mais aplicados e onde um bacharelado se encaixa nisso. Esse debate, por definição, não tem fim. Cada um de nós tem a sua visão e tá tudo bem.

Temos sorte de gostarmos da nossa área – podemos aplicar muito do quê aprendemos usando um computador doméstico

No fim do dia, saiba que a gente tem muita sorte de gostarmos e estarmos na nossa área. Nós podemos ter aulas teóricas em um momento e então irmos - até mesmo sozinhos - para uma prática bem avançada. Nossos amigos da engenharia civil e química, por exemplo, nem sempre tem a mesma sorte - não é todo mundo que tem um canteiro de obras ou uma planta química no quintal. Aproveite a oportunidade e bem-vindo(a)

Um termo bastante falado em computação é API. Normalmente, quando ele aparece, logo se fala de coisas como REST, HTTP, frameworks e etc. Pouco depois, a conversa cai no framework favorito da pessoa que está escrevendo ― Flask? Django REST Framework? Phoenix? Rails?? ― existe uma infinidade deles! Além disso, existe também uma infinidade de conceitos relacionados à arquitetura de API usada ― REST? SOAP? ― ao protocolo de comunicação usado ― HTTP? ― enfim, é uma conversa longa e cheia de caminhos possíveis.

Cada um desses conceitos merece atenção. Hoje, eu vou falar só do primeiro deles, a tal API. API é uma sigla ― Interface de Programação de Aplicações. Vou dar um "zoom" maior ainda e me focar em apenas uma palavra da sigla: interface.

Interfeice vs Interfáce

A palavra interface pode ser pronunciada de duas formas diferentes. Em Inglês, "interfeice" ou de forma mais aportuguesada, "interfáce". O acento não existe, é apenas para marcar que a segunda pronúncia faz referência à face, rosto, frente.

Quando falamos sobre interfaces, falamos de uma interação entre duas entidades, entre duas coisas diferentes, entre duas faces diferentes. Note o prefixo "inter", como em "internacional" ou "interestadual". Entre nações, entre estados e entre faces. Por fim, quando falamos em APIs, falamos em interfaces entre sistemas computacionais.

Interfaces Físicas e Computacionais

Em nosso dia-a-dia, interagimos com diversas interfaces físicas. O controle-remoto de uma televisão, os botões de uma cafeteira, o interruptor de um ventilador. Todos são exemplos de entidades que fazem a ponte entre o usuário e um outro recurso ― são interfaces.

Em nossos computadores, também temos diversas interfaces ativas à todo momento. O fato delas serem computacionais, porém, não significam que elas são APIs.

Uma API é uma interface computacional muito especial. Relembrando, a sigla significa "Interface de Programação de Aplicações". A característica fundamental de uma API é que ela é uma interface programável. Nós podemos, através de APIs, conectar diferentes pedaços de software uns aos outros, criando novas combinações e novas possibilidades.

Você pode alegar, corretamente, que você consegue escrever um código que aperta os botões da calculadora! Isso seria uma API certo? Não exatamente. Observe, a calculadora do meu sistema operacional não oferece nenhuma facilidade para que outro software utilize dela. Ela não foi feita para isso.

APIs permitem que softwares conectem-se entre si e utilizem as capacidades uns dos outros

Exemplos

Quando você utiliza uma biblioteca ou até mesmo uma função, ela expõe para você uma interface. A função sorted do Python, por exemplo, ela possui uma habilidade ― ordenar sequências ― que você pode querer usar em seu código. Os argumentos da função são o "rosto público" desse recurso.

‌Bibliotecas complexas como o NumPy expõem uma série de recursos na forma de funções, classes e módulos. Mais uma vez, os nomes, atributos e argumentos dessas entidades são a "face pública" de um recurso computacional que você pode usar em seu código.

Externo & Interno

Até aqui, desenvolvi a ideia da interface como sendo o "rosto público" de alguma entidade. Existe uma consequência importante dessa definição:

uma interface oculta as complexidades desnecessárias do recurso enquanto exibe uma face pronta para o usuário, que não precisa se preocupar com os detalhes.

Tome a função sorted que dei como exemplo ali em cima. Por baixo dos panos, ela é uma função em C embutida na linguagem Python, que se preocupa com diversos detalhes que não são necessários ao usuário da função. Um interface — e por consequência, uma API — bem feitas exibem o que é necessário, enquanto ocultam o que é irrelevante. Decidir onde traçar a linha entre o fundamental e o supérfluo é um problema na hora de arquitetar APIs (e muita gente tem opiniões muito fortes sobre isso!).

Documentação

Não é acidental que os dois exemplos que dei, eu mostrei print de uma documentação. Se uma API é uma interface pública e você não publica ela de forma alguma, quão útil ela de fato é? Ora, uma face pública que ninguém sabe como funciona, não é exatamente útil!

Documentação de código e de APIs é outro ponto que merece uma série de artigos só para si. Porém, quero deixar um recado importante para quem está começando nesse mundo

Uma API é tão útil por terceiros quanto melhor for a sua documentação. Uma face pública escondida, não é tão pública assim e não cumpre exatamente com seu papel.

HTTP, REST & a Web

Como vocês podem notar nos exemplos anteriores, não precisamos falar de Internet ao discutirmos APIs. No entanto, a Internet é um meio extremamente importante de conexão entre recursos computacionais diferentes. Portanto, um número gigantesco de APIs ― e de artigos sobre APIs ― é focado na web.

Eu quis escrever esse texto sem tocar nesses assuntos pois eles são densos e eu senti falta de um texto que lida com APIs sem pular para a Internet. No futuro, devo autorar mais materiais sobre essa parte.

Por hora ― e para satisfazer a curiosidades das eventuais pessoas decepcionadas por eu não ter tocado nisso ainda ― vou dar um breve resumo.

O protocolo HTTP define uma linguagem para que computadores se conversem. Nós podemos utilizar dessa linguagem pronta na hora de pensarmos numa API. Por exemplo, o HTTP vai nos dar formas estruturadas de comunicar erros — alguém pediu por algo que não existe? Retorne o famoso HTTP-404 ao invés de criar a sua solução customizada de erro!

O HTTP também nos dá formas robustas de responder perguntas do tipo "eu preciso servir esse texto. Ele possui traduções completas em 3 idiomas diferentes e traduções parciais em outros 5. Qual tradução do texto eu ofereço ao usuário?". De novo, ao invés de criarmos uma solução complexa, podemos utilizar das facilidades testadas ao longo do tempo que o HTTP nos oferece para isso.

REST, por outro lado, tem mais relação com estruturação, com a arquitetura da aplicação. Existe muito abuso de notação quando lidamos com REST mas, para um breve resumo, o REST vai nos facilitar pensar sobre as entidades que nossa aplicação contém e como arquitetar suas partes.

Um exemplo web

Um exemplo simples de API web é o MathJS. Ela permite que a gente tenha uma calculadora verdadeiramente programável e pela internet. Essa URL, por exemplo:

https://api.mathjs.org/v4/?expr=21*2

Irá retornar 42, o resultado da expressão 21*2. Observe como esse "site" aceita explicitamente um cálculo matemático através de um texto e retorna também um texto simples como resposta. Podemos, por exemplo, facilmente acessar esse recurso através de um terminal, com um comando como curl "https://api.mathjs.org/v4/?expr=21*2"

Como você pode ver, tanto pelo navegador, quanto pelo terminal, você consegue o resultado. O MathJS expõe uma API através do protocolo HTTP, uma língua que o seu navegador e o curl também falam.

Uma Reflexão sobre Conectividade na Web

‌Por fim, eu recomendo fortemente esse vídeo maravilhoso — e relativamente curto — sobre a história recente da interconexão de serviços na Internet.

Resumo

APIs são um assunto importantíssimo e grande. Como todo assunto que cumpre esses dois quesitos, existem muitos recortes que a gente pode fazer ao falar deles. Nesse texto eu quis focar na seguinte ideia:

APIs não são nada mais do que interfaces especiais e, como tal, devem ser vistas como a face externa de um recurso computacional.

APIs servem para interconectar recursos computacionais, permitindo que o seu código utilize recursos de outros serviços.

Agradeço aos meus colegas de Computação-UNICAMP ― Gabriel Lima, Ian Loron, Dede, Júlio e Murilo ― pela revisão e feedbacks

Listas e dicionários são duas estruturas de dados bastante usadas no dia-a-dia. Em resumo, listas servem para guardar sequências ordenadas de informações. Dicionários, por outro lado, permitem atrelar uma chave à um valor.

autores = ["Ramalho", "Bostrom", "Larson", "Pola", "Banks"]

dados = {
	"nome": "Bidu",
    "país": "Brasil"
}

Uma Nota Sobre Nomenclatura

Compreensão de Listas — é um termo que tem se tornado mais comum em Português do Brasil! Ainda me soa estranho, mas provavelmente isso vem da minha falta de hábito com o termo. É bom ter uma expressão "nossa" para coisas técnicas. Obrigado ao grande @villares pelo toque!

Sequência Ordenada — significa que a lista "lembra" a ordem em que os itens foram inseridos nela e não que esses itens serão magicamente ordenados como por exemplo em ordem alfabética ou algo do tipo. Em Inglês existem dois termos diferentes para isso: "ordered" para coisas como uma lista comum e "sorted" para uma lista que foi ordenada por algum critério como alfabético, crescente, etc

Criando Listas com Comprehensions

Suponha que você queira gerar 1000 números inteiros de 0 a 100 e então você quer separar todos os números que estão acima da média:

from random import randint

# Cria 1000 números de 0 a 100
n = []
for _ in range(1000):
	n.append(randint(0, 100))
    
    
média = sum(n) / 1000

# Filtra os números
selecionados = []
for i in n:
	if i >= média:
		selecionados.append(i)

Esse exemplo mostra dois casos úteis para usarmos list comprehensions:

1. Criar uma lista com base na repetição de uma chamada de função
2. Criar uma lista com base em outra lista

Criando Listas por Repetição de Chamadas

A lista n contém o resultado de 1000 chamadas para a função randint(0, 100). Nesse caso, aquele loop for pode ser reescrito assim:

n = [randint(0, 100) for _ in range(1000)]

Note que a chamada da função foi para o começo, a estrutura do loop foi para depois da chamada da função e o append desapareceu. Essa é a estrutura geral de uma list comprehension:

lista = [elemento_para_adicionar for variável in iterador]

Você pode usar a variável de iteração no cálculo do elemento que vai ser adicionado também. No meu exemplo eu usei underline porquê eu não precisava de fato do valor [0...1000), eu só queria repetir algo mil vezes. Em Python, quando precisamos colocar uma variável em algum lugar mas a gente não se importa com o valor dela de fato, usamos _ como nome.

Criando Listas com Base em Outra

Agora nós já temos nossa lista de mil números aleatórios! A segunda parte do nosso código tinha essa cara:

média = sum(n) / 1000

# Filtra os números
selecionados = []
for i in n:
	if i >= média:
		selecionados.append(i)

A criação de uma lista com base em uma outra, checando se os itens satisfazem uma condição é um filtro. Podemos implementar essa estrutura também com uma list comprehension:

média = sum(n) / 1000

# Filtra os números
selecionados = [i for i in n if i >= média]

Observe como a estrutura foi modificada de forma muito parecida com a anterior ― a coisa que queremos colocar na lista foi pro começo, logo em seguida nós "embutimos" o loop. A diferença agora é que depois do loop colocamos uma condicional. Essa estrutura pode ser lida como

"Adicione i em selecionados onde i são os elementos de n que possuem valor maior ou igual à média"

Cuidado com Abusos de Notação!

Comprehensions  são estruturas bem legais e interessantes em Python. Porém, elas podem ser abusadas. A função principal de uma comprehension é criar uma estrutura com base em outra. Ou seja, você usa uma comprehension quando se interessa pelo resultado dela.

Um abuso possível é usar de comprehensions como substitutas genéricas de loop for. Por exemplo, podemos imprimir todos os números de 0 à 10 assim:

[print(i) for i in range(11)]

A execução desse código será:

0
1
2
3
4
5
6
7
8
9
10
Out[1]: [None, None, None, None, None, None, None, None, None, None, None]

Usar de comprehensions quando na verdade você se importa apenas com um efeito colateral da função invocada e não com a estrutura gerada, pode comprometer a legibilidade do seu código, além de te dar uma estrutura vazia.

É tentador pensar que essa criação de lista também vai ter um impacto na performance. Isso eu deixo como Tarefa aos Leitores (TM). Dica: Profiling and Timing. Fiquem à vontade para discutir isso comigo no twitter também

Outro ponto de cuidado é o aninhamento extremo de coisas em uma comprehension. É possível fazer muita coisa com "one-liner", os código de uma linha só, e tem gente que adora coisas do tipo. Eu particularmente acho legal o poder que Python e outras linguagens tem de fazer isso, mas para códigos em produção que serão mantidos futuramente, eu evito. A foto de capa desse artigo é um péssimo exemplo de comprehension.

A legibilidade do código é uma propriedade extremamente importante em equipes de software. Tomem cuidado com isso e não tenha medo de usar de code reviews para discutir com seus colegas e validar que sua solução está legível! Legibilidade é um conceito subjetivo e divergências podem acontecer.

Criando Dicionários com Comprehensions

Assim como listas, dicionários também podem ser criados com comprehensions. Suponha que eu queira construir um dicionário onde a chave é um número e o valor é esse número ao quadrado. Podemos fazer com um loop for normal:

quadrados = {}

for i in range(100):
	quadrados[i] = i ** 2

Esse código irá nos dar o dicionário:

{0: 0,
 1: 1,
 2: 4,
 3: 9,
 4: 16,
 5: 25,
 6: 36,
 7: 49,
 8: 64,
 9: 81,
 10: 100,
(...)

Observe que dicionários, diferente de listas, são inicializados com { } ao invés de [ ]. Isso será refletido na dict comprehension também:

quadrados = {i: i**2 for i in range(100)}

Note como essa estrutura é muito similar à de uma list comprehension, com a diferença que agora temos um par chave: valor. Podemos ler esse código como

"Adicione i como chave, i ao quadrado como valor, para cada i de 0 até 99"

Filtrando Dicionários

Temos nosso dicionário de números e seus valores ao quadrado! Vamos fazer duas separações ― separar todas as chaves pares e separar todos os valores que são maiores que 100. Como dicionários, ao contrário de listas, possuem duas "entidades" para cada entrada, podemos filtrar por cada uma delas.

Para filtrar as chaves pares, podemos fazer algo do tipo:

chaves_pares = {}

for chave in quadrados:
	if chave % 2 == 0:
    	chaves_pares[chave] = quadrados[chave]

Esse código vai nos dar:

{0: 0,
 2: 4,
 4: 16,
 6: 36,
 8: 64,
 10: 100,
 12: 144,
 14: 196,
 16: 256,
(...)

"Bidu, mas e o método items em dicionários?" Vamo um passo de cada vez :D

Esse loop for pode ser reescrito de maneira similar com a filtragem de listas:

chaves_pares = {chave: quadrados[chave] for chave in quadrados if chave % 2 == 0}

De novo, temos uma estrutura que evolui da criação normal usando comprehensions, acrescentando uma condicional ao final. Podemos ler como

"Adicione chave com o mesmo valor que ela possui em quadrados, para cada chave em quadrados, se o resto da divisão da chave por 2 for 0"

Filtrando Valores

O segundo problema que propus foi filtrar todos os valores maiores do que 100. Uma iteração comum em dicionários, for x in dicionário, faz um loop através apenas das chaves. Porém, podemos utilizar da seguinte sintaxe: for chave, valor in dicionário.items(). Ela nos permite iterar pelas chaves e valores de uma só vez:

data = {"nome": "Bidu", "país": "Brasil"}

for chave, valor in data.items():
	print(f"O valor de {chave} é {valor}")   

Esse código imprime

O valor de nome é Bidu
O valor de país é Brasil

Nosso filtro pode ser implementado assim:

valores_grandes = {}

for chave, valor in quadrados.items():
	if valor > 100:
		valores_grandes[chave] = valor

Esse código irá nos retornar:

{11: 121,
 12: 144,
 13: 169,
 14: 196,
 15: 225,
 16: 256,
 17: 289,
 18: 324,
 (...)

E ele também pode virar uma comprehension!

valores_grandes = {c: v for c, v in quadrados.items() if v > 100}

Essa comprehension pode ser lida como

"Adicione chave com o mesmo valor que ela possui em quadrados, para cada chave e valor em quadrados, se valor for maior do que 100

Resumo

Nesse post eu discuti sobre como comprehensions são uma sintaxe útil do Python para quando queremos criar estruturas com base em outras ― seja filtrando ou transformando os valores originais ― ou com base em repetições de uma certa computação.

Fica também o alerta quanto ao abuso dessas estruturas, comprehensions não são um "loop for chique", elas servem apenas para substituir um tipo específico de loop ― quando queremos criar uma estrutura nova.

Não são apenas listas e dicionários que suportam comprehensions, elas também são compatíveis com outras estruturas como sets e tuplas!

Fazer um código legível e bonito é algo importante no nosso dia-a-dia, especialmente quando colaboramos com demais colegas. Um código que é mal formatado e mal estruturado é cansativo de ler e difícil de compreender.

A formatação de um código é só um pedaço da história, mas um pedaço muito importante. Ela não é a única responsável pela legibilidade do código ― um projeto mal estruturado, feito de classes e funções com responsabilidades mal definidas pode até ser bem formatado, mas será difícil de compreender.

No começo de minha carreira, eu não gostava muito da ideia de formatação automática de código. Por um lado, eu acho que eu era um pouco orgulhoso em relação à isso e não estava afim de perder "controle" do meu código. Por outro lado, mais de 10 anos atrás, essas ferramentas não eram exatamente boas, pelo menos não as que eu conhecia.

Quanto ao primeiro argumento, hoje eu vejo essa resistência à perda do "controle" como algo meio bobo. A formatação do código por mais importante que seja, não é exatamente o foco do trabalho de um desenvolvedor ou sua finalidade. O centro do nosso trabalho é a abstração de problemas do mundo real para dentro de um algoritmo e a solução desse problema através de ferramentas computacionais, levando em consideração as restrições de projeto que temos.

Além disso, se nosso código deve seguir um livro de estilo padronizado ― como é cada vez mais comum atualmente ― qual é o mérito em gastar tempo e esforço para cumprir um padrão definido? Humanos são bons em criar, em fazer coisas novas. É aí que mora nosso diferencial, o que for automatizável, podemos deixar que o computador faça por nós e nos deixe mais livres.

Já em relação ao segundo argumento, hoje nós temos diversas ferramentas de formatação automática que são cada vez mais robustas. O foco do restante desse artigo é o Black, um formatador automático para Python.

Black

A instalação do Black pode ser feita usando pip install black . Se seu ambiente estiver bem configurado, você conseguirá digitar black --help em seu terminal e ver algumas de suas opções de uso. Caso você queira, pode explorar o funcionamento dele no Black Playground.

O Black permite diversas formas de execução. Podemos, por exemplo, invocá-lo direto da linha de comando com uma string de código:

black -c "x=2  * 3+4"

E ele te retornará a expressão propriamente formatada, x = 2 * 3 + 4 com os espaços corretos.

Explorando Erros com Pylint

Considere agora esse código, bem mal formatado mas ainda assim é válido:

def fatorial(n):

    result=1

    for i in(range(1, n+1)):
        result*=i
    return result

print(  fatorial(   3))
print(fatorial(2     ))
print(fatorial(10     ))

Uma forma de avaliarmos a situação desse código é usando o pylint. Esse arquivo está salvo em minha máquina como "black_sample01.py". Rodando pylint black_sample01.py , nos dá a seguinte resposta:

************* Module black_sample01
black_sample01.py:2:10: C0326: Exactly one space required around assignment

    result=1

          ^ (bad-whitespace)

black_sample01.py:7:0: C0325: Unnecessary parens after 'in' keyword (superfluous-parens)
black_sample01.py:8:14: C0326: Exactly one space required around assignment

        result*=i
              ^^ (bad-whitespace)

black_sample01.py:11:5: C0326: No space allowed after bracket
print(  fatorial(   3))

     ^ (bad-whitespace)

black_sample01.py:11:16: C0326: No space allowed after bracket
print(  fatorial(   3))

                ^ (bad-whitespace)

black_sample01.py:12:21: C0326: No space allowed before bracket
print(fatorial(2     ))

                     ^ (bad-whitespace)

black_sample01.py:13:0: C0304: Final newline missing (missing-final-newline)
black_sample01.py:13:22: C0326: No space allowed before bracket
print(fatorial(10     ))

                      ^ (bad-whitespace)

black_sample01.py:1:0: C0114: Missing module docstring (missing-module-docstring)
black_sample01.py:1:0: C0103: Argument name "n" doesn't conform to snake_case naming style (invalid-name)
black_sample01.py:1:0: C0116: Missing function or method docstring (missing-function-docstring)

--------------------------------------------------------------------
Your code has been rated at -3.75/10

Existem erros de parênteses desnecessários, erros de espaço em branco e várias linhas desnecessárias também. Podemos agora explorar o black.

Verificando Possíveis Mudanças

Chamando o black com a flag --check , ele apenas nos conta se o arquivo seria reformatado ou não. Isso é útil para usar em servidores de CI e evitar que arquivos mal formatados subam para a base:

$ black --check black_sample01.py

would reformat black_sample01.py
Oh no! 💥 💔 💥
1 file would be reformatted.

(Mais sobre CI e ferramentas assim em breve!)

Nós podemos usar a flag --diff para ver as mudanças que seriam feitas

$ black --diff black_sample01.py

--- black_sample01.py	2020-05-20 13:52:23.495800 +0000
+++ black_sample01.py	2020-05-20 13:55:56.786380 +0000
@@ -2, 19 +2, 16 @@
 Módulo que oferece um fatorial iterativo
 """

 def fatorial(n):

*    result=1
*    result = 1

-
-
-

*    for i in(range(1, n+1)):
*        result*=i
*    for i in range(1, n + 1):
*        result *= i

     return result

+print(fatorial(3))
+print(fatorial(2))
+print(fatorial(10))

-print(  fatorial(   3))
-print(fatorial(2     ))
-print(fatorial(10     ))
reformatted black_sample01.py
All done! ✨ 🍰 ✨
1 file reformatted.

Honestamente, é meio raro eu usar essas duas flags no meu dia-a-dia. Uma situação em que eu costumo usar a --diff é quando eu estou trabalhando em uma base de código pela primeira vez e estou pensando se vou ou não sugerir uma mudança de estilo. Rodar o --diff me permite estimar o quão trabalhoso seria reformatar a base toda. Já a flag --check eu uso em servidores de CI (Integração Contínua) mesmo.

Reformatando com Black!

E finalmente a reformatação é bem direta. Basta invocar o black sem flags e com o arquivo:

$ black black_sample01.py

reformatted black_sample01.py
All done! ✨ 🍰 ✨
1 file reformatted.

O arquivo em si será modificado:

"""
Módulo que oferece um fatorial iterativo
"""

def fatorial(n):
    result = 1

    for i in range(1, n + 1):
        result *= i
    return result

print(fatorial(3))
print(fatorial(2))
print(fatorial(10))

Usando Black no Dia-a-Dia

Okay, formatamos um arquivo! Mas como garantir isso ao longo do processo?
Eu gosto de usar três abordagens diferentes:

• Direto no meu editor de texto
• Como um hook pre-commit no git
• No servidor de CI

A parte do hook e do CI merecem um artigo só pra elas. Quanto ao editor, seja lá qual for, ele provavelmente já tem uma integração com o Black.

Ultimamente, tenho usado o VSCode como editor principal. A configuração no VSCode pode ser global ou específica de projeto. Uma vez habilitado, você pode autoformatar seu código apertando CTRL + Shift + I

Configuração Global

No caso da configuração global, abra as configurações em File > Preferences > Settings ou digite CTRL + , . Na barra de busca, digite "python formatting provider". Você deverá ver essa opção:

Selecione "black" na lista e pronto!

Configuração Local

A configuração local de projetos é feita através do arquivo .vscode/settings.json. Basta adicionar nele a chave "python.formatting.provider": "black" para habilitar o black no seu projeto atual.

Autoformatar ao Salvar ou Não?

Tudo isso que a gente fez habilitou a invocação manual do Black ― você precisa apertar CTRL + Shift + I para formatar o código. O VSCode e muitos outros editores dão uma outra opção ― autoformatar ao salvar.

Particularmente, eu deixo essa opção desativada nas configurações globais. Muitas vezes eu trabalho em código que envolve outros colegas, em projetos que não usam black ou que simplesmente possuem um padrão de formatação diferente. Autoformatar nesses casos é ruim. Quando trabalho em projetos novos, deixo habilitado!

Projetos com código "feio" ou seguindo um padrão de formatação diferente, podem ser problemáticos. Mas mais problemático ainda é quebrar a consistência interna do projeto. Usar CamelCase para dar nomes em variáveis não é comum em Python e o PyLint vai reclamar disso. Porém, se você está trabalhando em um projeto que usa CamelCase para tudo, mantenha a consistência e ― talvez ― proponha a mudança de padrão em um segundo momento. Mas isso é assunto pra outro post!