CJFP 05 - 12 de julho de 2024
Se você está lendo isso, é tarde demais! Este artigo foi escrito e entregue aos assinantes do nosso boletim informativo há uma semana. Se desejar receber nossos artigos mais recentes assim que forem lançados, considere inscrever-se em nosso boletim informativo CaJu’s ‘Fresh Picks’ em www.caju-creative.com/newsletter.
Leia até o fim para obter uma recomendação especial sobre meu livro favorito para aprender a linguagem de programação Python do zero.
“O Zen do Python” como Método e Poesia
Em “My Qual-to-Quant Journey”, um artigo que escrevi para o LinkedIn detalhando minha decisão profissional de expandir das artes para as ciências, apresentei a ideia de que criativos e chefes de STEM podem aprender muito com os métodos uns dos outros. Gostaria de expandir esse sentimento hoje usando um dos módulos Python mais inesperados como referência concreta, mas antes de fazer isso, preciso apresentar Tim Peters a você.
Tim Peters é um engenheiro de software, muito bom nisso. Isso não atrairá leitores não técnicos, mas alguns de seus elogios incluem o desenvolvimento de seu próprio algoritmo de classificação, além de ser um grande contribuidor para a linguagem de programação Python de código aberto e um dos principais desenvolvedores originais do CPython.
Ele tem credibilidade, mas o que acho que pode chocar os leitores é, provavelmente, o motivo pelo qual Tim Peters é mais conhecido é um poema que ele escreveu chamado “The Zen of Python”.
Assim como acontece com toda linguagem humana natural, as linguagens de computador têm algum grau de interpretabilidade. Um programador tem um certo grau de liberdade em sua sintaxe, ordem de funções, convenções de nomenclatura, etc. Essa última palavra é reveladora: Convenção. Assim como quando os humanos falam uns com os outros com vários graus de imprecisão, dependendo da pessoa com quem você está falando, dependendo da quantidade de contexto que a pessoa com quem você está falando tem, a mesma frase pode ser estruturada de muitas maneiras diferentes para fins bem-sucedidos.
Certos erros gramaticais são inaceitáveis, como a omissão de objetos ou predicados de sua frase. Mas nem sempre. A linguagem formal que sua escola patrocinada pelo estado lhe ensinou enquanto crescia é, na verdade, um gradiente com fala perfeita de um livro didático de um lado e balbucios incoerentes do outro. Cabe a quem interpreta a língua fazer várias suposições sobre o que está sendo dito ou solicitar mais informações se a imprecisão for terminal para a compreensão. As linguagens de programação podem ser semelhantes.
Para ser fácil de ler, escrever e aprender, Python foi projetado para refletir a fala humana e, portanto, possui muitas das imprecisões da fala humana. Assim como acontece com as linguagens naturais, as convenções tiveram que ser desenvolvidas e popularizadas para o que torna um trecho de código gramaticalmente correto, doravante denominado “Pythônico”.
É aqui que encontramos Peters, o poeta. Na tentativa de formalizar muitas das convenções aprendidas mecanicamente para a codificação Pythonic, Tim Peters escreveu o seguinte:
O Zen do Python por Tim Peters
Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Flat é melhor que aninhado.
Esparso é melhor que denso.
A legibilidade conta.
Casos especiais não são especiais o suficiente para quebrar as regras.
Embora a praticidade supere a pureza.
Erros nunca devem passar silenciosamente.
A menos que seja explicitamente silenciado.
Diante da ambiguidade, recuse a tentação de adivinhar.
Deve haver uma - e de preferência apenas uma - maneira óbvia de fazer isso.
Embora esse caminho possa não ser óbvio à primeira vista, a menos que você seja holandês.
Agora é melhor do que nunca.
Embora nunca seja melhor do que *agora*.
Se a implementação for difícil de explicar, é uma má ideia.
Se a implementação for fácil de explicar, pode ser uma boa ideia.
Namespaces são uma ótima ideia. Vamos fazer mais deles!
Isso é poesia. Não há como evitar isso. Este é um bom poema escrito por um programador de computador e o que eu gostaria de fazer aqui hoje é percorrer este poema linha por linha e explorar primeiro o que ele significa no domínio de uma peça genérica de código Python e, em segundo lugar, o significado maior por trás da linha e as implicações que ela tem para todos os esforços criativos (dos quais a programação deve ser considerada).
Você também pode acompanhar! Se você for um novato, simplesmente pesquise no Google “Como usar Python em um (insira seu tipo de máquina aqui)”. Depois de ter um interpretador Python3 instalado e funcionando, digite o seguinte:
importar isto
O Zen do Python vem com todas as cópias da linguagem de programação Python, então agora você deve tê-lo completo.
Bonito é melhor que feio
Desde o início, não tenho escolha a não ser invocar a Filosofia. A natureza da beleza, ou estética, tem sido um tema ferozmente debatido (deve-se assumir) desde que os humanos começaram a fazer uso do conceito. Algo bonito pode ser simples para alguns e complexo para outros. Pode haver beleza na conformidade e pode haver beleza na singularidade. A beleza pode ser imposta a nós pelo mundo e também pode ser subjetivamente definida a partir de dentro de nós.
Platão pensava que a beleza era uma forma ideal além do mundo físico. Aristóteles pensava que era ordem, simetria e propósito. Plotino pensava que a beleza vinha da unidade e do divino. Tomás de Aquino vinculou a beleza à harmonia, proporção e integridade. Burke distinguiu a beleza como delicada e agradável, diferente do sublime inspirador. Hume disse que a beleza é subjetiva e está nos olhos de quem vê. Kant acreditava que a beleza era um prazer desinteressado que reivindica um acordo universal. Hegel via a beleza como a expressão sensual do divino. Nietzsche via a beleza como a interação entre ordem e caos.
Infelizmente para nós, eles estão bem.
A beleza é difícil de definir, mas tem um aspecto universal: bonito é melhor que feio. Esse aspecto da beleza está embutido em sua definição e, portanto, é uma base sobre a qual podemos construir.
Em seu livro Zen and The Art of Motorcycle Maintenance, Robert Pirsig redefiniu a busca pela beleza no campo da estética como uma busca inatamente biológica pela Qualidade. Eu gosto bastante disso. Ele postula que mesmo um organismo unicelular foge da forte luz solar em busca de sombra, o que ele está fazendo é buscar um ambiente de qualidade superior, mais adequado para viver; mais um lindo.
Essa é a definição de Beleza que gostaria de adotar aqui.
Para um programador, isso significa manter o código legível. Conhecemos um código feio quando o vemos, especialmente em uma linguagem como Python, que realmente tenta orientar os usuários para a legibilidade.
A codificação pode ser facilmente descartada pelos criativos como não-criativa, mas só se pensa assim se nunca realmente tentou programar. Quando você encontra uma solução elegante e simples para um problema lógico difícil em uma linguagem de codificação, é uma sensação de felicidade tão sublime, que rivaliza com a sensação que se tem em um momento eureka ao criar arte.
A codificação e os esforços criativos buscam clareza e qualidade. Mesmo que alguém tente fazer algo “feio”, eles tentam fazê-lo de acordo com algum raciocínio e assim podem atingir um nível de “bela feiúra” se a forma dessa criação for tal que torne a interpretação do seu significado uma experiência agradável para os seres humanos.
Código Python feio:
def saudação(nome):
if nome: print("Olá, " + nome + "!")
else: print("Olá!")
Lindo código Python:
def saudação(nome):
saudação = f"Olá, {nome}!" if name else "Olá!"
imprimir(saudação)
Explícito é melhor que implícito
É aqui que acho que terei mais problemas para sintetizar uma lição que se aplica tanto a programadores quanto a criativos. Em geral, acredito que o marketing se sai melhor quando tenta transmitir mensagens implicitamente. Afinal, esse é o objetivo de toda narrativa criativa. Não basta simplesmente dizer “O orgulho pode ser perigoso para o seu trabalho e para a sua saúde”. É muito mais duradouro contar a história do afogamento de Narciso por se apaixonar por seu reflexo na água ou pela lenta e constante tartaruga batendo na rápida e arrogante lebre.
Envolver um significado explícito em uma história e levar o leitor a chegar a uma conclusão é um dos mais antigos empreendimentos humanos. Também não é a isso que esta parte do poema se refere.
Esta linha literalmente se refere a declarar seus propósitos para partes específicas do seu código, em vez de confiar no leitor para inferir suas intenções. Isso ajuda o código à prova de futuro. Você pode saber o que está fazendo no momento, mas alguém (ou até você mesmo) lendo o mesmo código posteriormente pode não ter ideia do que você está tentando realizar ou como.
Existem situações em que obscurecer suas intenções é um método retoricamente poderoso para criar um impacto duradouro em seu leitor. No entanto, se você está escrevendo código e seu leitor é um programador, o único impacto duradouro que a obscuridade tem é a frustração.
Ao escrever código, gosto de me perguntar constantemente: “Se eu fosse atingido por um caso agudo de amnésia neste momento, quão difícil seria descobrir o que estou tentando realizar aqui?” Depois de decifrar algum código difícil de interpretar, você anotará cada linha, usará docstrings e declarará suas intenções logo no início do documento. Todo. Solteiro. Hora.
Uma lição para os criativos tradicionais é não confiar muito no humor interpretativo do seu público. Por exemplo, se uma pessoa está olhando seu anúncio, a parte difícil de chamar a atenção dela acabou! Desse ponto em diante, você deverá facilitar a vida deles. Muitas pessoas dirão que você deve reduzir a confusão em um anúncio ou remover detalhes para não aborrecer o leitor. Há alguma verdade nisso, mas há um limite para essa linha de pensamento.
Se alguém foi enganado por algo que você criou, trate-o com o mesmo respeito que trataria alguém pessoalmente. Não tema os detalhes. Se alguém estiver interessado em seu produto ou serviço e tiver que vasculhar seu anúncio em busca de mais informações que não existem, você poderá perdê-lo quando já o tiver “preso”, por assim dizer.
Há momentos em que ser implícito pode ter um impacto, mas na maioria das vezes, explícito é melhor que implícito.
Código Python implícito:
def calcular_area(r):
return 3,14159 * (r ** 2) if r > 0 else "Erro: o raio deve ser maior que zero"
imprimir(calcular_area(5))
Código Python explícito:
# Definindo uma função para calcular a área de um círculo
def calcular_area(raio):
"""
Calcule a área de um círculo.
Esta função usa um número inteiro diferente de zero e não negativo ou um ponto flutuante como argumento para o raio, verifica sua validade, calcula a área do círculo e retorna a área como um ponto flutuante. A área é definida como a = pi * r^2.
Parâmetros:
raio (float ou int): o raio do círculo, que deve ser maior que zero.
Retorna:
float: a área do círculo.
str: uma mensagem de erro se o raio não for maior que zero.
"""
# Verifique se o raio é válido
se raio <= 0:
return "Erro: o raio deve ser maior que zero"
# Calcule a área
área = 3,14159 * (raio ** 2)
# Retorna o resultado
área de retorno
# Chamando a função para um raio de 5
imprimir(calcular_area(5))
Simples é melhor que complexo
É aqui que o poema começa a se tornar contraditório. Com o tempo fará sentido, mas por enquanto pode parecer que estou indo contra o que disse anteriormente. Peters faz isso como um recurso retórico; usando dicotomias contraditórias para enfatizar significados mais profundos.
Existe uma diferença entre complexo e obscuro. Há uma diferença entre simples e vago. Nosso trabalho como programadores e criativos é buscar aquilo que melhore a experiência do nosso público-alvo.
Como continuação do último ponto, deve-se ter como objetivo fornecer ao leitor o máximo de informações necessárias para que ele se familiarize com o que você criou para ele. Dito isso, a maneira como você fornece essas informações deve ser direta, e não desnecessariamente detalhada.
Isso pode ser o pragmatismo americano que estou falando, mas essa é uma reclamação que tenho com o ensino superior também há algum tempo. Ao tentar mudar corações e mentes ou educar o público, por que diabos você revestia sua mensagem ou descobertas com palavras de cinco dólares que mesmo a maioria dos acadêmicos não entenderia completamente? Não adianta tentar ser obscuro de propósito, além de talvez mascarar uma falta de substância ou compreensão. Parafraseando Einstein, se você não consegue explicar algo de maneira simples, então você não o entende bem o suficiente.
Ao programar, pense em seu objetivo final ou resultado ideal. Escreva as etapas que você precisa seguir para atingir seu objetivo final. Tente escrever na ordem inversa e de onde você acha que deveria começar. Quando coisas novas lhe ocorrerem, escreva-as no meio. Continue escrevendo as etapas até ver um caminho de A a Z. Depois de escrever todas as etapas, condense e combine. Escreva os métodos que você usaria para realizar cada etapa. Procure redundâncias ou formas de realizar múltiplas tarefas ao mesmo tempo. Python tem muitos métodos avançados que podem alcançar em uma linha de código o que outras linguagens levariam várias linhas de código. Python tem muitos módulos e bibliotecas facilmente acessíveis que podem executar funções avançadas para você. Outras pessoas fizeram o trabalho braçal e estão gentilmente dispostas a compartilhar seus métodos com você! Você também pode aceitá-los!
Não vou argumentar que a arte simples é superior à arte complexa. A arte deveria desafiar você às vezes, deveria fazer você pensar. Mas isso não quer dizer que todo filme precise ser um Inception ou que todo romance precise ser um Ulisses. Uma boa regra, não importa o que você esteja fazendo, é tentar realizar exatamente o que você pretende, sem concessões, com o menor número possível de peças móveis. Isso não é atender a um público “preguiçoso”, é apenas ter a cortesia de não exigir um diploma avançado para aproveitar o que você fez.
Código Python complexo:
def is_prime_complex(n):
"""Verifique se um número é primo com lógica complexa."""
se n <= 1:
retornar Falso
se n <= 3:
retornar Verdadeiro
se n % 2 == 0 ou n % 3 == 0:
retornar Falso
i = 5
enquanto i * i <= n:
se n % i == 0 ou n % (i + 2) == 0:
return Falso
i += 6
retornar Verdadeiro
print(is_prime_complex(17)) # Verdadeiro
print(is_prime_complex(18)) # Falso
Código Python simples:
da importação do sympy isprime
def check_prime_simple(n):
"""Verifique se um número é primo usando sympy."""
return isprime(n)
print(check_prime_simple(17)) # Verdadeiro
print(check_prime_simple(18)) # Falso
Complexo é melhor que complicado
Não se chamaria um céu noturno estrelado de simples, nem provavelmente o chamariam de complicado. É lindo em sua complexidade. Tanto a arte quanto o código devem lutar pelo mesmo.
Sua primeira ordem de pensamento deve ser Simples > Complexo, porém, em muitas situações, você pode não conseguir evitar a complexidade e tudo bem! Coisas complexas também podem ser lindas!
Assim como no exemplo anterior, você deve se esforçar para tornar suas criações tão simples quanto necessário para que seu público possa apreciá-las. Se manter a simplicidade deixa seu público confuso ou querendo mais, então seja mais complexo, mas se você já está adicionando detalhes mais esclarecedores, então eles devem ser exatamente isso: Esclarecedores.
Às vezes, ao trabalhar em Análise de dados, um analista é solicitado a descrever descobertas estatísticas avançadas para partes interessadas que, segundo todos os relatos, não foram educadas o suficiente para compreendê-las completamente. Sempre insisto que isso não é uma desculpa para tratar o CEO com luvas de pelica. Os profissionais que atuam podem lidar com uma ou duas fórmulas, elas só precisam ser apresentadas de forma acessível.
Quando algo que você está fazendo para outra pessoa precisa ser complexo, tudo bem. É aí que você precisa voltar às linhas anteriores deste poema. A complexidade pode ser bela, mas ser assim significa não estar confuso. Para mim, complexidade significa muitos passos, mas muitos passos no mesmo caminho. A complicação consiste em muitos caminhos diferentes entrelaçados.
Se o seu caminho tiver muitos passos, tudo bem, desde que seus passos sejam claros e seu caminho seja direto.
Código Python complicado:
def fibonacci_complicated(n):
def fib_helper(a, b, contagem):
return a if count == 0 else fib_helper(b, a + b, count - 1)
retorne 0 se n <= 0 else 1 se n == 1 else fib_helper(0, 1, n)
print(fibonacci_complicated(10)) # Saída: 55
print(fibonacci_complicated(50)) # Isso levará muito tempo devido à ineficiência
Código Python complexo:
def fibonacci(n, memo={}):
se n <= 1:
retornar n
se n não estiver no memorando:
memorando[n] = fibonacci(n-1, memorando) + fibonacci(n-2, memorando)
retornar memorando[n]
print(fibonacci(10)) # Saída: 55
print(fibonacci(50)) # Saída: 12586269025
Plano é melhor que aninhado
Só não conte ao Sir Mix-A-Lot *rimshot*
No caminho para completar seu código ou criar sua arte, às vezes você pode se deparar com projetos dentro de projetos. Se estiver construindo uma casa de passarinho, você provavelmente não terá todas as partes e peças prontas ao seu redor. Você vai precisar fazer um planejamento, ir até a loja comprar a madeira, cortar os pedaços, revesti-los com verniz, etc. Você se propôs a realizar uma grande tarefa, mas no caminho percebe que há tarefas menores que devem ser concluídas primeiro.
No entanto, se você estivesse descrevendo o processo de criação de uma casinha de passarinho para um amigo e continuasse explicando cada subtarefa em detalhes antes de passar para a próxima etapa, você deixaria seu amigo louco se ainda pudesse chamá-lo assim quando chegasse ao fim. Em vez disso, o que uma pessoa típica pode fazer é mencionar cada uma das subtarefas em sequência, em vez de se aprofundar em cada uma de suas etapas. Esta não é exatamente uma analogia 1:1, mas acho que demonstra muito bem esse ponto.
Python é uma linguagem muito tolerante. Por exemplo, se você quiser determinar se 5 * 20 = 100 e quiser descobrir isso da maneira mais irritante possível, faça algo assim:
def dumb_calc(expressão):
se expressão == 0:
print("A resposta é 0!")
expressão elif:
if isinstance(expressão, str):
partes = expressão.split('*')
if len(partes) == 2:
tente:
num1 = int(partes[0].strip())
num2 = int(partes[1].strip())
resultado = num1 * num2
se resultado == 100:
print("Sim, a resposta é 100!")
senão:
se o resultado > 100:
print("Não, a resposta é maior que 100.")
senão:
se resultado < 100:
print("Não, a resposta é menor que 100.")
exceto ValueError:
print("Entrada inválida! Não foi possível converter para números inteiros.")
senão:
print("Formato inválido! Use o formato 'a * b'.")
senão:
print("Entrada inválida! A expressão deve ser uma string.")
senão:
print("A expressão é nenhuma ou falsa!")
dumb_calc("5 * 20") # “Sim, a resposta é 100!”
Isso é “aninhamento” ou ter condições lógicas dentro de condições lógicas, e é provavelmente a pior maneira possível de verificar se a expressão “5 * 20” é de fato igual a 100, mas é um código totalmente válido e executado sem problemas.
No entanto, só porque você pode fazer algo, nem sempre significa que você deveria.
Para o bem do usuário final ou do público, geralmente é melhor evitar o aninhamento quando possível. Às vezes, é inevitável e a omissão do aninhamento pode, na verdade, infringir uma das sugestões anteriores. Então, quando possível, tente ser “plano” ou trabalhar sua lógica no mesmo nível.
Isso evita que o usuário tenha que seguir níveis de lógica cada vez mais profundos, reduzindo a carga cognitiva.
Em projetos criativos, isso se traduz em como se deve ver os momentos de complexidade necessária. Se você estiver gravando um vídeo de instruções, não se prenda a detalhes dentro de detalhes. Não há problema se um processo tiver muitas etapas, desde que essas etapas sejam claras. É sempre bom fazer mais vídeos de instruções detalhando etapas específicas do processo, mas se você tentar cobrir tudo de uma só vez, perderá pessoas.
Código Python aninhado:
def get_grade(pontuação):
se pontuação >= 90:
se pontuação <= 100:
retornar 'A'
senão:
se pontuação >= 80:
retornar 'B'
senão:
se a pontuação >= 70:
retornar 'C'
senão:
se pontuação >= 60:
retornar 'D'
senão:
retornar 'F'
print(get_grade(85)) # Saída: B
print(get_grade(72)) # Saída: C
Código Python simples:
def get_grade(pontuação):
se 90 <= pontuação <= 100:
retornar 'A'
se 80 <= pontuação < 90:
retornar 'B'
se 70 <= pontuação < 80:
retornar 'C'
se 60 <= pontuação < 70:
retornar 'D'
retornar 'F'
print(get_grade(85)) # Saída: B
print(get_grade(72)) # Saída: C
Esparso é melhor que denso
Se precisar de tempo, deixe levar! Se precisar de espaço, dê-lhe algum espaço!
Aposto que a maioria dos leitores astutos já está começando a entender, mas continuarei mesmo assim.
Para permanecer explícito e não temer a complexidade, talvez você precise enfrentar o desafio estético de como organizar algo que você fez e que tenha muitas partes móveis.
Há um câncer que infecta grande parte do trabalho criativo hoje em dia e o nome desse câncer é minimalismo. Só porque algo é longo não significa necessariamente que não tenha público. As pessoas reservam tempo para aquilo que melhora suas vidas. Não perca o tempo das pessoas com rodeios, mas também não sinta que precisa sobrecarregar cada linha de código ou segundo de filme com tanto material que sobrecarregue seu público.
Ao escrever código, não tenha pressa. Use espaçamento adequado e comente generosamente, mesmo que isso signifique que seu código fique um pouco longo. Ao criar arte, não há problema em usar espaços vazios ou deixar uma linha de diálogo pairar no ar por um momento, desde que isso acentue um ponto ou significado específico. Algumas cenas nas séries modernas são muito mais longas do que o necessário e é fácil dizer que isso é simplesmente para aumentar o tempo de execução. Não é disso que estou falando aqui.
Se você gasta muito tempo criando algo que gostaria que outras pessoas experimentassem, é perfeitamente válido se dedicar a momentos excepcionais. Seja criando código ou arte, deixe seu público experimentar sua criação pelo que vale a pena, não a barateie por uma questão de brevidade.
Portanto, esparso é melhor que denso, mas se eu pudesse acrescentar um adendo seria que denso é melhor que insípido.
Código Python denso:
def função_densa(x): retorne x*2+5 se x>10 senão x/2-5
print(dense_function(15)) # Saída: 35
print(dense_function(5)) # Saída: -2,5
Código Python esparso:
def função_esparsa(x):
# Verifica se x é maior que 10
se x > 10:
# Dobre o valor e adicione 5
resultado = x * 2 + 5
senão:
# Reduza o valor pela metade e subtraia 5
resultado = x / 2 - 5
retornar resultado
print(sparse_function(15)) # Saída: 35
print(sparse_function(5)) # Saída: -2,5
A legibilidade conta
Isso pode ser desnecessário dizer, mas no espírito geral do poema, ainda assim deveria ser dito.
“A informação quer ser gratuita” é um famoso truísmo atribuído a Stewart Brand, cofundador do Whole Earth Catalog. É algo que descobri ser geralmente correto. A informação parece querer ser gratuita, mas existem outras forças além do escopo deste artigo que a impedem de ser assim. Ainda assim, a informação certamente tenta o seu melhor.
Os humanos são criaturas sociais. A arte é criada para ser compartilhada e apreciada, o código é criado para ser usado. É claro que há exceções, mas essas afirmações geralmente são verdadeiras, até onde posso ver.
Qualquer coisa que você escreve, seja um romance ou um script Python, deve ser escrito para ser lido. Ou seja, você não está escrevendo para si mesmo. Mesmo no caso dos diários pessoais que mantive, uma parte profunda da minha psique sempre tem em mente uma pessoa que pode estar remexendo nas minhas coisas depois da minha morte.
Em Python, gosto de ter em mente que todas as funcionalidades das quais dependo foram meticulosamente trabalhadas por gerações de programadores que doaram seu tempo para um projeto de código aberto. Eles se esforçaram para garantir que os métodos que escreveram, aqueles que estou usando, fossem documentados de tal forma que eu pudesse entendê-los mais facilmente.
Em outros empreendimentos criativos, algumas das piores artes que são feitas são feitas apenas com o ego do diretor em mente. É nisso que penso sempre que sou forçado a assistir a um filme de Michael Bay. Eles cheiram a alguém fazendo isso por si mesmo. Eu comparo isso com os filmes de George Miller, que são ousados e difíceis de criar porque não comprometem a visão do espetáculo. Eles desafiam o público sem segurar as mãos (sim, até mesmo Babe e Happy Feet). Seu novo filme Furiosa é uma aula magistral absoluta em respeitar a inteligência do seu público sem confundi-lo com densidade.
Resumindo, faça o que você faz pensando nos outros.
Código Python quase ilegível:
def calc_avg(nums):
se len(nums) == 0:
return Nenhum
return soma(nums) / len(nums)
imprimir(calc_avg([10, 20, 30, 40, 50]))
imprimir(calc_avg([]))
Código Python legível:
def calcula_média(números):
"""
Calcule a média de uma lista de números.
Parâmetros:
números (lista): uma lista de valores numéricos.
Retorna:
float: a média dos números na lista. Retorna None se a lista estiver vazia.
"""
se não forem números:
return Nenhum
soma_total = soma(números)
contagem = len(números)
média = soma_total / contagem
média de retorno
se __name__ == "__main__":
números_amostra = [10, 20, 30, 40, 50]
resultado_média = calcular_média(números_amostra)
se Average_result não for Nenhum:
print(f"A média de {sample_numbers} é {average_result:.2f}")
senão:
print("A lista está vazia. Não é possível calcular a média.")
Casos especiais não são especiais o suficiente para violar as regras
Este é outro que é difícil, mas não impossível, de traduzir para a esfera criativa tradicional.
A forma como interpreto isso para codificação é que os métodos são importantes. Ajuda quem lê seu código ou quem você fornece seu código a analisá-lo melhor. Isso significa que quando equipes de programadores se reúnem, os problemas podem ser melhor resolvidos usando mais ou menos as mesmas mentalidades. Isso significa que seguir as convenções mesmo quando sair do script pode ser mais fácil.
Houve momentos em que fiz um trabalho de análise para alguém e precisei, por qualquer motivo, iniciar uma análise secundária para resolver um problema auxiliar. É incrivelmente tentador nesses momentos, sabendo que este projeto secundário é só para mim e não deveria surgir novamente, pular algumas das regras acima. Ser indiferente a certas coisas, não ser explícito, não comentar liberalmente, etc. Eu diria que 50% das vezes que fiz isso, isso voltou a me morder de uma forma ou de outra.
As convenções são importantes para a construção de uma doutrina. Isto é tão verdadeiro para as artes quanto para as ciências. Para minha primeira graduação, frequentei uma escola de artes. Quando a maioria das pessoas pensa em escola de artes, elas pensam em entregar desenhos em guardanapos e receber adesivos de girassol em vez de notas. Minha experiência não poderia ter sido mais longe disso. Minha experiência na escola de arte foi aprender muitas habilidades comerciais e muita metodologia. No final veio a ênfase em aprender as regras para saber quando quebrá-las, mas nos primeiros três anos tudo não passou de observar os mestres e repetir.
As convenções permitem construir escolas de pensamento e movimentos em oposição a estilos pessoais. Cada caso que você encontrar será tecnicamente um caso “único” ou especial. Não existem dois momentos no tempo exatamente iguais. Contudo, a marca de uma boa metodologia é saber se ela é suficientemente robusta para lidar com casos marginais. Pessoalmente, acho que é por isso que as convenções “Pitônicas” funcionam melhor como poemas do que como um conjunto estrito de regras.
É claro que você não deve quebrar as regras, mas, felizmente, as regras são estruturadas de forma a permitir uma interpretação criativa e ao mesmo tempo permanecer segura dentro de seus limites.
Caso de uso:
Um desenvolvedor precisa escrever um script rápido e único para processar uma grande lista de números e encontrar a soma de todos os números maior que um limite específico. O script deve ser usado apenas uma vez e executado em uma máquina local, portanto, o desempenho e a facilidade de manutenção são menos preocupantes. O desenvolvedor pode ficar tentado a escrever um código muito compacto e menos legível para economizar tempo.
Solução não-Pythônica: compacta, mas difícil de ler
limite = 50
números = [12, 75, 34, 60, 23, 90, 45, 51]
resultado = soma(n para n em números se n > limite);print(f"Soma de números maiores que {limiar}: {resultado}")
Solução Pythonic: legível e mantém convenções
def sum_above_threshold(números, limite):
"""
Calcule a soma dos números maiores que um determinado limite.
Parâmetros:
números (lista): uma lista de valores numéricos.
limite (int): o valor do limite.
Retorna:
int: a soma dos números maior que o limite.
"""
retornar soma (n para n em números se n > limite)
se __name__ == "__main__":
limite = 50
números = [12, 75, 34, 60, 23, 90, 45, 51]
resultado = sum_above_threshold(números, limite)
print(f"Soma dos números maiores que {threshold}: {resultado}")
Embora a praticidade supere a pureza
É uma função acima da forma, baby! Esta é uma colina onde sempre morrerei.
Se você precisar se desviar das regras, faça valer a pena e faça-o de uma forma que interprete criativamente as convenções orientadoras, em vez de quebrá-las completamente.
Em cada novo empreendimento, você deve sempre procurar aprender primeiro seus limites. Começando no caminho para estudar uma nova ciência? Pesquise antes de tudo onde termina e onde começam as ciências adjacentes. Aprenda seus métodos e sua história. Descubra o que os melhores da área fazem. Aprenda a metodologia geral que você “descobre” e veja os problemas para os quais a metodologia foi criada. Depois de entender por que as metodologias existem, só então você poderá experimentar novas metodologias.
As regras raramente devem ser tão rígidas a ponto de serem quebradas. Esse é o propósito dos juízes. Se todas as leis fossem eternas e literais, raramente haveria necessidade de sua interpretação! Então, se você precisa quebrar as regras, faça-o, mas pelo menos você deve ser capaz de explicar exatamente por que está fazendo isso.
Exemplo de código Python, mas pouco prático:
importar csv
def parse_csv(caminho_do_arquivo):
"""
Analise um arquivo CSV e extraia colunas específicas.
Parâmetros:
file_path (str): o caminho para o arquivo CSV.
Retorna:
dict: um dicionário com dados extraídos.
"""
com open(file_path, newline='') como csvfile:
leitor = csv.reader(csvfile)
cabeçalho = próximo(leitor)
dados = {}
para linha no leitor:
se linha:
chave = linha[0]
valor = linha[1]
dados[chave] = valor
dados de retorno
se __name__ == "__main__":
file_path = 'data.csv'
parsed_data = parse_csv(file_path)
imprimir(parsed_data)
Exemplo de código prático, mas não Python:
importar csv
com open('data.csv', newline='') como arquivo csv:
leitor = csv.reader(csvfile)
cabeçalho = próximo(leitor)
data = {row[0]: row[1] para linha no leitor se linha}
imprimir(dados)
Erros nunca devem passar silenciosamente
Aqui está uma boa e suspeito que você saberá onde quero chegar.
Na codificação, você tem vários motivos pelos quais um código pode falhar na execução. Eles são chamados de erros de tempo de execução e vêm em diversas formas. Sua sintaxe pode estar um pouco errada. Esqueceu um período? Todo o seu programa não será executado. Você pode ter confiado demais no Python para assumir algo e ele assumiu de forma diferente do que você esperava. Tentou obter a raiz quadrada da string “545”? Seu programa irá falhar. Talvez você tenha cometido um erro inocente, como tentar dividir pelo número 0! Mesmo que todos os seus tipos de dados e sintaxe estejam corretos, seu programa ainda exibirá um grande, vermelho e embaraçoso ZeroDivisionError.
Isso, ao contrário do que você pode pensar se não tiver muita experiência em codificação, é bom! Muitas pessoas adoram Python porque ele comete erros com frequência e especificamente. Compare isso com uma linguagem de programação como C, que raramente gera erros, a menos que algo esteja seriamente errado. Você precisa criar muitas redes de segurança ao programar em C, enquanto o Python faz grande parte do trabalho braçal para você. Muito, mas não todos.
A marca de um bom programador é o tratamento de erros. Você deve ter notado as declarações “Try” e “Except” em um dos exemplos anteriores. Isso instrui o programa a tentar algo sabendo que poderá gerar um erro se algo estiver errado. Em vez de travar todo o programa, você tem contingências integradas que serão implementadas caso ocorra um tipo específico de erro.
Alguns erros, como SyntaxErrors, para os quais você provavelmente não deseja abrir exceções. Se eles estão aparecendo, a culpa é do programador e devem ser corrigidos em vez de isentos. No entanto, um ZeroDivisionError em um programa de calculadora pode ter vindo de um usuário bem-intencionado! Podemos pensar no futuro e programar uma mensagem útil que informe o usuário sobre esse erro sem travar o dispositivo.
Quanto mais erros pudermos planejar com antecedência e escrever exceções, melhor. No mínimo, quando nossos programas gerarem erros, entenderemos melhor exatamente onde e por que os erros estão ocorrendo no programa.
A lição aqui é universal: os erros não são o inimigo, os erros são sem dúvida a parte mais crucial do aprendizado de qualquer coisa.
Em funções criativas tradicionais, já fui tentado a encobrir ou esconder erros que cometi. Talvez em parte devido à minha educação religiosa, a minha culpa geralmente me dominava a ponto de me confessar nesses casos. Não consigo me lembrar de uma única vez em que um erro ou erro de minha parte tenha sido tão catastrófico quanto parecia a princípio. Todos se tornaram momentos de ensino e, em muitos casos, foi a última vez que eu ou alguém da minha equipe cometemos o mesmo erro.
Se você cometer um erro ou se a vida lhe der um erro, sorria! Você acabou de aprender algo. Se você for inteligente, construirá novas maneiras de lidar com essa situação no futuro. É assim que os bugs se tornam recursos.
Código de erro silencioso:
def read_file(caminho_do_arquivo):
com open(file_path, 'r') como arquivo:
return file.read()
content = read_file('non_existent_file.txt')
se conteúdo:
imprimir(conteúdo)
senão:
print("O arquivo não pôde ser lido, mas não sabemos por quê.") # Esta parte não será executada, pois uma exceção interromperá o programa.
Código detalhado de tratamento de erros:
def read_file(caminho_do_arquivo):
tente:
com open(file_path, 'r') como arquivo:
return file.read()
exceto FileNotFoundError:
print(f"Erro: o arquivo em '{file_path}' não foi encontrado.")
exceto PermissionError:
print(f"Erro: permissão negada ao tentar ler '{file_path}'.")
exceto exceção como e:
print(f"Ocorreu um erro inesperado: {e}")
content = read_file('non_existent_file.txt')
se conteúdo:
imprimir(conteúdo)
senão:
print("O arquivo não pôde ser lido devido a um erro.")
… A menos que seja explicitamente silenciado
Ok, nem todos os erros são oportunidades de ensino. Todo engenheiro sabe que existem problemas recorrentes que são melhor ignorados do que corrigidos. O truque é ser criativo com sua ignorância.
Existem algumas mensagens de aviso que fazem mais mal do que bem quando se trata de legibilidade. Haverá alguns erros em programas mais longos que, durante toda a sua vida, você não será capaz de entender por que eles aparecem e, mais estranho ainda, por que o programa ainda funciona se você os suprimir.
Às vezes, em nome da praticidade e de prazos realistas, você precisa que o Python simplesmente cale a boca e confie em você. Você precisa ter MESMO certeza se vai fazer isso, mas deve saber que é algo que você pode fazer. Muitas funções possuem um parâmetro “silence_error” que você pode ativar. Apenas lembre-se: se você tiver problemas, você não ouviu isso de mim.
Em funções criativas, às vezes os erros vêm de dentro. Às vezes você terá erros internos. Isso deve ser ignorado em silêncio ou, melhor ainda, tratado. Dúvidas, distrações e colegas de trabalho duvidosos fazem parte do processo. Planeje-os com antecedência, mas se eles tenderem a ocorrer novamente, você deve saber que simplesmente ignorá-los costuma ser o melhor curso de ação.
Diante da ambiguidade, recuse a tentação de adivinhar
Gostaria de filosofar um pouco aqui sobre método.
Sair na floresta e anotar todas as suas observações sobre os insetos que encontra não faz de você um biólogo. Por que? Porque a Biologia é uma disciplina com doutrina. É uma escola de estudo com acólitos que realizam seus rituais. Para se tornar um biólogo, é preciso aprender esses métodos precisos para que suas observações combinem bem com outras.
Chegamos então a um problema: como é que vários tipos de “Ologistas” explicam novos tipos de observações que são diferentes das que surgiram antes? É aqui que entra o método científico. Você sabe qual é. Hipótese, experimento, teoria, experimento, teoria, etc.
Aqui está a pergunta de um milhão de dólares: de onde vêm as hipóteses? Que método existe para criá-los? Esta questão tem intrigado os filósofos da ciência há milênios. As hipóteses parecem vir de compreensões instintivas do assunto. Suposições em outras palavras.
É por isso que esta regra diz que suposições são uma tentação. É fácil criar uma teoria aceitável na mente e continuar com ela como se fosse a verdade dada por Deus. As estrelas dos reality shows fazem isso o tempo todo.
No entanto, esta não é uma forma científica de prosseguir. Quando alguém se depara com algo que nunca encontrou antes, deve-se esperar que ele tenha a experiência de ter aguçado seus instintos, o que deve ajudá-lo na criação de uma hipótese, que deve levá-lo de volta ao método e à condução de experimentos.
Você deve sempre planejar o desconhecido em qualquer área, seja ela criativa, de codificação ou científica. Parte do avanço em direção à compreensão consistirá em apresentar suposições fundamentadas, mas seu processo nunca deve parar aí. Pergunte a si mesmo: "Se minha suposição fosse verdadeira, o que eu esperaria ver como resultado? Quais poderiam ser seus catalisadores? O que precisaria mudar para tornar minha suposição falsa?" e então, o que é crucial, você precisa mudar essas coisas para ver se sua suposição ainda se mantém.
A maneira científica de fazer isso é chamada de Teste de Hipóteses, com o qual tenho minhas próprias queixas metafísicas, mas vou guardá-las para outro dia.
Deve haver uma — e de preferência apenas uma — maneira óbvia de fazer isso
Este me confundiu quando comecei. Só depois de criar alguns programas do zero é que comecei a dar certo.
Uma coisa é, em uma sala de aula, receber um problema específico e depois ensinar uma ferramenta específica para resolver esse problema específico. Isso é ótimo para aprender os detalhes de várias partes da linguagem, mas não ensina um dos aspectos mais cruciais da programação: saber quais das milhares de ferramentas à sua disposição usar a qualquer momento, sem instrução.
Se eu quisesse escrever um script que uma vez por semana pegasse todas as principais manchetes e depois as enviasse para uma lista de endereços que eu armazeno em meu disco rígido e atualizo ocasionalmente, eu poderia, de cabeça, pensar em cerca de 20 maneiras de fazer exatamente isso. Isso é incrivelmente assustador no início. No entanto, depois de ter um pouco de experiência e ver os tipos de coisas que os programadores realmente bons fazem, você começará a ver que certas ferramentas são feitas sob medida para determinados problemas.
Se você está construindo algo e começa a ter a sensação de que deve haver uma maneira mais fácil, é quase certo que existe. Stack Overflow é seu amigo aqui. Alguém teve o mesmo problema, alguém encontrou alguma solução alternativa e alguém sentiu a vergonha de perceber que a resposta estava bem na sua cara o tempo todo. Tudo isso faz parte.
Descobri que isso vai muito além do campo da programação. Até mesmo de empreendimentos tradicionais criativos. A mente humana é muito melhor em identificar “O que deveria ter sido feito” do que em “O que deveria ser feito”. Retrospect é uma superpotência humana, não a descarte.
Se você fizer algo e pensar: “Ah, droga, eu realmente deveria ter feito isso de uma maneira diferente”, seu cérebro está destacando um padrão para seu benefício futuro. Às vezes, o caminho óbvio só é óbvio em retrospecto, mas ainda assim é informativo. Pelo menos na programação, tem-se a vantagem de reescrever e executar novamente.
Continue firme, não importa o que seja, e, eventualmente, o caminho óbvio se tornará cada vez mais claro, até que seja o único que poderia ter sido.
Embora esse caminho possa não ser óbvio à primeira vista, a menos que você seja holandês
Eu não falo holandês, mas ainda assim… haha, que frase ótima.
Esta linha é uma referência ao cara que inventou o Python, Guido van Rossum, que é holandês. Isso significa que cada método dentro do Python foi feito pensando em um problema específico. Se a técnica adequada não lhe ocorrer a princípio, significa apenas que você precisa de mais tempo para se familiarizar com as possibilidades do Python.
Como o Python é de código aberto, isso significa que todos os dias novas bibliotecas e módulos são criados e disseminados por usuários nobres resolvendo novos problemas. Você nunca estará 100% familiarizado com eles, mas as chances são sempre de que, não importa o problema que você esteja enfrentando, alguém já enfrentou o mesmo e, pela bondade de seu coração, publicou a solução gratuitamente online para tornar sua vida mais fácil.
Como falante de inglês, a melhor clareza que posso dar aqui é ecoar o sentimento anterior. Continue assim até que o ambíguo se torne óbvio.
Ou contrate um professor de holandês.
Agora é melhor do que nunca
Tempo é uma palavra com B caprichosa. Toda percepção e razão se devem ao fenômeno do tempo que impede que todos os momentos ocorram no mesmo instante. No entanto, como doador de tudo, o tempo é um bem precioso cujo suprimento é finito.
Ok, agora que as considerações existenciais foram eliminadas, considere a frase “Tempo é dinheiro”. A veracidade dessa afirmação irá variar dependendo da sua posição no organograma da sua empresa, mas se você estiver trabalhando em uma equipe voltada para objetivos, até certo ponto ela será verdadeira para você.
A maioria dos problemas não melhora com o tempo (embora haja raras exceções). Falando apenas da minha própria experiência, descobri que a procrastinação é muitas vezes um mecanismo de enfrentamento do medo ou da indiferença. Se tenho medo do fracasso, inconscientemente adiarei algo até que se torne um problema tão grande que seja forçado a lidar com ele. Literalmente a pior opção possível. Se eu não tiver uma opinião muito elevada sobre um problema, ele escapará da minha mente até se tornar um problema tão grande que sou forçado a lidar com ele. Literalmente, a segunda pior opção possível.
A lição aqui é entender que “nunca” realmente não existe. Se você está ignorando ativamente um problema, então ele continua a ser um problema, pelo menos para o seu bem-estar. Você deve resolver os problemas antecipadamente.
Como procrastinador reformado, não vou mentir para você: o caminho para a recuperação é difícil e exige muita prática. Você precisa encontrar suas próprias maneiras de lidar de maneira saudável com o medo, a indiferença ou qualquer outro catalisador para sua procrastinação. Sua solução provavelmente será diferente, mas deixe-me tentar convencê-lo a começar sua jornada com um grande benefício que descobri.
Nos últimos anos, resolver problemas ou tarefas assim que possível tornou-se quase como um jogo para mim. Nas primeiras horas após encontrar um novo problema ou receber uma nova tarefa, você está no Velho Oeste, baby! Não há respostas erradas! Vá absolutamente selvagem. Cutuque e cutuque. Experimentar! Deixe a criatividade fluir. Divirta-se porque você ainda tem todo o tempo do mundo! Esse tipo de exploração inicial de um problema é divertido porque os riscos ainda são relativamente baixos e o problema ainda não é urgente. Um bônus adicional é que esse tipo de brincadeira não estruturada é a base da criatividade humana.
Quando você começa cedo, você tem tempo para jogar. Hora de brincar significa hora de encontrar soluções novas e criativas para os problemas. Resolver problemas de forma criativa fará você se sentir bem e o ajudará a lutar contra o medo ou a indiferença.
O mais cedo que você pode começar é agora mesmo! Se as tarefas parecerem assustadoras, divida-as em tarefas menores. Faça algo fácil, depois faça algo difícil, guarde as coisas médias para quando estiver cansado mais tarde.
Meu pai sempre me disse quando eu era criança que o futuro e o passado são ilusões. Existe apenas o agora e sempre haverá apenas o agora. Demorei cerca de 25 anos para entender, mas mal consigo descrever o quanto minha vida melhorou quando finalmente melhorou.
Embora nunca seja melhor do que *agora*
Eu realmente deveria ter lido antes de tentar escrever essas dicas em tempo real. Mas é isso que quero dizer quando digo que Peters é propositalmente contraditório. Ele está incitando o leitor a pensar como um programador. Você precisa ser muito metódico em um ambiente invadido por casos marginais. É assim que você faz isso.
Este verso do poema não quer dizer que muitas vezes é melhor nunca fazer algo do que começar imediatamente. Não estou dizendo que “nunca” tenha muito mérito. Significa que “*agora* agora” muitas vezes não tem muito mérito.
Obviamente é melhor começar algo agora do que mais tarde, quando puder. No entanto, essa não é uma regra universal. Se começar algo o mais rápido possível vai atrapalhar o processo, então espere! Muitas vezes é melhor nunca fazer algo do que se precipitar e bagunçar tudo.
Não há problema em reservar um pouco de tempo de preparação antes de começar um projeto de cabeça. Se em sua pesquisa você achar que seria benéfico abandonar totalmente a tarefa e dedicar seu tempo a outra coisa, faça-o! Ambos os métodos ainda envolvem iniciar algo imediatamente, mesmo que essa coisa não seja a tarefa principal.
Na codificação, isso pode significar ler um livro explorando o tipo de trabalho com o qual você está lidando ou pesquisar no GitHub ou Stack Overflow por projetos semelhantes ou problemas que alguém possa ter encontrado.
Quando trabalhei em funções criativas tradicionais, se eu tivesse algum tempo de preparação para um projeto, pediria ao meu gerente um tempo de pesquisa. É excepcionalmente difícil fazer algo que você nunca encontrou antes. Se você estiver fazendo um podcast, precisará ouvir muitos podcasts. Fazendo um vlog? Assista a muitos vlogs. Você entendeu.
Há mérito em começar de cabeça e brincar quando se trata de projetos que você está supervisionando pessoalmente. No entanto, se você estiver trabalhando em um projeto no qual outras pessoas têm interesse, geralmente é melhor respirar fundo, fazer alguma pesquisa e começar um pouco mais tarde do que *agora* com um plano de jogo.
Se a implementação for difícil de explicar, é uma má ideia
Eu adoro esse. É aplicável a muitas coisas.
Se estiver trabalhando como analista de dados, uma coisa que você terá que fazer com frequência são reuniões stand-up. Várias vezes por semana, você terá que se levantar e orientar alguém sobre a lógica de sua análise, incluindo suas metodologias, suas fontes, suas teorias, suas confirmações, etc. Se você se surpreender, isso pode significar algumas coisas: você perdeu uma solução mais óbvia ou toda a operação estava condenada desde o início.
Python foi desenvolvido para incentivar soluções simples e inteligentes para problemas complexos. Se você não consegue orientar um novato em seu código, preciso trazer Einstein de volta quando digo que você provavelmente não o entende tão bem quanto pensa.
A codificação e as funções criativas tradicionais têm em comum a tarefa de apresentar ideias criativas aos gerentes. Quando trabalhei em ambos, meu dia a dia normalmente era enfrentar um desafio ou uma oportunidade, ter um pouco de tempo para ter ideias e, em seguida, apresentá-las a uma equipe.
Se uma ideia fosse escolhida, era esperado que eu a concretizasse. Depois de concluído, tive novamente que apresentar o projeto às partes interessadas. As partes interessadas 99,999% das vezes terão MBAs e se especializarão em apertos de mão profissionais. Não se deve esperar que eles saibam o que é uma distribuição gaussiana ou sejam capazes de intuir por que você optou por escrever sua própria função personalizada em vez de importar uma, mas se você seguiu as diretrizes acima, isso não deveria importar.
Vamos considerar a linha inversa e seguinte,
Se a implementação for fácil de explicar, pode ser uma boa ideia
Se, ao orientar alguém em seus processos de pensamento, as etapas parecerem óbvias e claras, então o Python, modelado a partir do idioma inglês, deverá ser capaz de traduzir essas ideias em código com clareza semelhante.
Quando você cria algo, seja um programa, um vídeo, uma música ou uma pintura, você deve ser capaz de explicar em termos relativamente simples por que tomou as decisões que tomou. Conforme mencionado no último boletim informativo, não trate seu público como idiotas, mas também não os trate como candidatos a doutorado.
Uma das melhores maneiras de desenvolver uma ideia por si mesmo é explicá-la para um novato. Experimente! Se não puder, talvez repense sua abordagem.
Apenas observe a advertência na segunda afirmação! pode ser uma boa ideia. Se você explicar alguma coisa e todas as pessoas na sala concordarem com a cabeça, sem perguntas de acompanhamento, talvez seja necessário mirar mais alto ou considerar a ideia de que você pode não entender o problema tão bem quanto pensava.
Namespaces são uma ótima ideia. Vamos fazer mais deles!
Minha única reclamação é que Peters termina isso de forma um pouco anticlimática, mas acho que ele faz isso porque é um pouco engraçado, então não vou usar isso contra ele.
Estávamos em um rolo temático! Vai me matar terminar isso com uma nota técnica, então vamos ver se consigo realmente transformar isso em uma lição universal pela última vez.
Na programação, um namespace é um conjunto de identificadores ou palavras-chave reservadas que ajudam a evitar conflitos de nomenclatura. Por exemplo, uma declaração muito importante em Python é a declaração “if”. Se eu nomear uma variável aleatória como “se”, então me impedirei de usar instruções condicionais em meu programa completamente. O namespace integrado do Python reserva esta palavra-chave. Quando tento executar if = 123, o Python me interrompe, gera um erro e me chama de idiota antes que eu possa causar qualquer dano sério. Obrigado, espaços para nome.
Namespaces também ajudam a manter os programas organizados, separando o código em seções e níveis lógicos. Compreender os namespaces significa entender como usá-los a seu favor, por exemplo, quando eles se aplicam ou não.
Eles são realmente uma buzinada e o Python deveria continuar fazendo mais deles!
Agora, acho que isso se aplica às funções criativas em geral está na nomenclatura da área de cada um. Trabalhei com pessoas das disciplinas de codificação e produção de mídia que não usavam termos precisos da indústria para as coisas que descreviam. Esse pouco de imprecisão linguística ocasionalmente fazia com que detalhes cruciais se perdessem na tradução.
Quanto mais velho fico, mais percebo o quanto um discurso preciso pode ser uma vantagem em qualquer empreendimento. Sempre haverá um pouco de imprecisão na linguagem humana, esse é o nome do jogo. Mas minimizá-lo tanto quanto possível pode poupar muitos problemas.
Certa vez, um editor de áudio me disse que já havia compactado um episódio de podcast quando na verdade o equalizou . Certa vez, um PA me disse que eles embalaram os C-Stands quando na verdade embalaram os tripés. Certa vez, um analista me disse que um determinado recurso de conjunto de dados havia sido normalizado quando na verdade havia sido padronizado.
Na fala cotidiana, essas pequenas diferenças geralmente podem ser inferidas graças ao contexto e ao poder da capacidade humana para a linguagem. No entanto, em um ambiente profissional, entender mal o namespace em que você está pode causar muitas dores de cabeça, na melhor das hipóteses, e, na pior, desemprego.
Na minha época de escola de artes, percebi que muitos dos meus colegas tinham uma espécie de fobia quando se tratava de detalhes, então os detalhes se tornaram meu estilo pessoal! É por isso que meu lema não oficial passou a ser “Não tema os detalhes”. A maioria das pessoas desiste depois de algumas camadas. Se você conseguir manter o foco e se aprofundar um pouco mais, será recompensado por sua compreensão sempre que delegar uma tarefa ou concluir um projeto de equipe com êxito.
Certa vez, ao ministrar um workshop sobre técnicas de edição de áudio, decidi começar minha palestra com eletromagnetismo e física de ondas. Meu processo de pensamento foi que, para compreender completamente o ambiente abstrato em que você se encontra, é necessário compreender as peças mais atômicas do meio, que são os elétrons, no caso da edição de áudio.
O objetivo de The Zen of Python é familiarizá-lo com uma interpretação poética do namespace e das convenções do Python. Os programadores que adotam a programação pitônica operam como dançarinos estudantes do mesmo gênero. Podem nem sempre mover-se em uníssono, mas porque todos subscrevem um conjunto semelhante de características definidoras e pressupostos artísticos, podem fazer parte de um todo coeso enquanto ainda pensam de forma independente.
Eu adoro The Zen of Python porque ele próprio adota uma abordagem única para resolver um problema razoavelmente sério. Conforme mencionado acima, ter muitas pessoas operando de forma independente em uma área que exige colaboração só levará ao desastre. A programação é um desafio único, como mencionei anteriormente, porque é altamente metódica na teoria e altamente volátil na prática. Essa situação atinge o cerne do que a poesia faz.
A poesia não pretende dar um significado definido. Pretende apontar para verdades subjetivas. Se o meio da poesia fosse a verdade objetiva, então alguém acabaria por escrever o poema final que encapsula todos eles. A poesia é bela em sua incompletude subjetiva. Um único poema pode chegar perto, mas nunca captar o maravilhoso fenômeno da subjetividade humana e, assim, deixar aberta a oportunidade para futuros poetas.
É por isso que considero The Zen of Python um bom poema. Você agora foi introduzido no culto do Python. Se você obedecer aos seus princípios, não deverá ter problemas ao interagir com outros crentes. E quando as regras explícitas se revelarem inadequadas, você saberá exatamente como proceder na definição de sua própria versão do Zen Pitônico.
Livro recomendado para aprender Python
Costumo dizer às pessoas que aprendi Python três vezes. Uma vez em um programa de pós-graduação que esperava que eu já conhecesse, uma vez por conta própria e uma vez em uma aula oficial de programação para minha segunda graduação. A primeira tentativa foi um estrondo, mas a segunda teve tanto sucesso que eu poderia ter ensinado a terceira.
O diferencial foi o livro seguinte. Foi um entre muitos, mas estou guardando o resto para um artigo futuro descrevendo todos os meus livros favoritos sobre Python, dos quais “Think Python”, de Allen B. Downey, é um deles.
“Pense em Python: como pensar como um cientista da computação”, por Allen B. Downey
O livro tem uma nova edição que aborda e trata com elegância o tópico iminente da IA na codificação, que é uma das muitas razões pelas quais acredito que este livro continua a ser tão valioso para tantos.
Não é apenas uma introdução incrível à linguagem de codificação Python, mas também ajuda alguém novato em programação de computadores em geral a começar a aprender conceitos que são aplicáveis a muitas outras linguagens de computador.
Ele não chega a funções mais avançadas, como compreensão de listas ou APIs e a Biblioteca de Solicitações, mas é mais do que compensado ao preparar alguém (mesmo alguém com zero experiência em codificação) para sair por conta própria e aprender os métodos avançados.
Se quiser experimentar este livro, use o link a seguir para comprá-lo. CaJu Creative faz parte do programa de afiliados da Amazon. Quando você usa o link a seguir, recebemos uma pequena porcentagem de qualquer compra oficial e isso nos ajuda a continuar fazendo Fresh Picks da CaJu.
Compre “Think Python: Como pensar como um cientista da computação” AQUI.
Até a próxima, fique atualizado.
-Casey