![PythonBrasil[6]](http://www.python.org.br/banners-pythonbrasil/countdown_fullbanner.gif)
Python ainda é pythônico?
Eu estava lendo um (longo) artigo que fala sobre várias coisas sobre como desenvolvíamos software no passado e como desenvolvemos hoje, etc… E num determinado momento ele fala sobre bibliotecas, frameworks e sobre um conceito denominado por ele “radius of comprehension“.
O conceito de “radius of comprehension” é simples: dado um determinado trecho pequeno de código, quanto de código a mais você precisa ler para entender o que ele faz. Quanto menor o “radius of comprehension” melhor.
Ao ler isso eu me lembrei de uma palestra do Luciano Ramalho onde ele fala que gosta da linguagem Python (e da idéia de algo ser ‘pythonico’) porque ela “cabe na cabeça” dele e acho que isso tem uma relação direta com a idéia de “radius of comprehension“.
Eu também pensava da mesma forma que o Luciano. Achava que Python “cabia” na minha cabeça. Mas hoje eu devo admitir que isso é parcialmente verdade.
Em primeiro lugar eu acho que a linguagem vem crescendo demais desde a versão 2.2. Adicionando funcionalidades e “acúcares sintáticos” cujos benefícios podem ser facilmente questionados.
Mas não vou falar muito da linguagem não. Vou falar de alguns módulos da biblioteca padrão do Python que são praticamente impossíveis de serem usadas sem ter a documentação à mão:
- logging – esse é o pior de todos. Não tem uma única vez que eu não preciso recorrer à documentação do módulo pra fazer algo “bobo”. Sei que um “logging.log(…)” basta para o básico, mas se você precisa de algo básico+1 você já se vê obrigado a ler toda a documentação do módulo. Acho que o problema desse módulo foi tentar copiar o log4j do mundo Java. Todos nós conhecemos o gosto por “over engineering” dos programadores Java.
- ConfigParser – não tenho muito a dizer. Porque esse módulo precisa daqueles conceitos complicados de configurações “globais”, busca de arquivos em múltiplos diretórios, etc. Ele poderia implementar o simples e fácil e deixar as extensões para bibliotecas de terceiros.
- email – precisei usar esse aqui uma única vez e desde então eu tremo de medo sempre que alguém me pede pra “manipular e-mails” em uma aplicação Python. Sei que manipular e-mails é complicado se considerarmos a quantidade de “variações dos padrões” existentes num serviço que tem quase a idade da Internet, mas as abstrações devem ser construídas para nos poupar desses detalhes, não?
- xml.dom e xml.sax – eu já não gosto de XML, imagina manipular XML com essas duas bibliotecas “podres”. Se eu pego um código pra dar manutenção e esse código usa uma dessas duas bibliotecas eu triplico o valor do serviço.
- re – neste caso eu não acho que seja muito culpa do Python, mas peça pra alguém que conheça regex mas não conheça Python explicar a diferença entre re.search() e re.match(). Ou mostre pra ele uma regex com “(?P<foo>.*)” significa.
Além dessas tem outras que não vou me lembrar. Tem também algumas bibliotecas, módulos e frameworks no atual “eco sistema” do Python que simplesmente não entram na minha cabeça:
- Zope e Plone – a turma do PythonBrasil já conhece essa história. Eu tentei bem umas 3 vezes estudar essa dupla e nas 3 eu não consegui ir além de abrir a interface de administração do Zope. Mas de duas uma: ou sou burro demais ou o troço é desnecessariamente complicado. Por sorte o ZODB funciona separadamente porque esse sim é poderoso e fácil de usar.
- Buildout – esse eu já usei basicamente pra instalar alguns programas mas é uma caixa preta completa pra mim. Não tenho certeza, mas acho que ele nasceu no (ou em função do) Zope/Plone e talvez isso explique um pouco disso. Eu não sei direito se ele é um sistema de build, um sistema pra criação de ambiente de desenvolvimento, ou se é algum sistema alienígena de IA.
Eu sei que os problemas que temos que resolver hoje em dia são bem mais complexos do que os que tínhamos que resolver quando comecei a programar, mas problemas complexos não precisam de soluções que deixem transparecer essa complexidade.
A Triveos é especializada no desenvolvimento de aplicações Web e utiliza Python e Django em grande parte de seus projetos. Tendo como base esse know-how no uso de Python e Django criamos o Curso de Desenvolvimento Web com Python e Django nas modalidades in-company e online.
Concordo com td isso ai, Plone/Zope são extremamente chatos pra desenvolver! o buildout é outro monstro, e pra domina-los demora mtoooo tempoo!!! mas a linguagem Python continua pythonica! ;D
Olá Osvaldo !
Eu me aprofundei e conheci o python de verdade agora a pouco, faz pouco tempo, e gostei d+ dele pois ele me possibilita trabalhar com muitas coisas, executar muitas tarefas e além de tudo me possibilita trabalhar de forma simples, como de forma complicada. Todos nós geralmente tendemos a complicar as coisas,e podemos utilizar python para isto, mas quem sabe como simplificar, também pode utilizar python ! Saca !
Python é simplesmente python, simples e completo !
abraço..
Não acho que ter que ler a documentação seja uma desvantagem tão gigante assim.
Mas claro, pensando em “caber na cabeça”, faz todo sentido.
Post interessante =)
Ótimo post Osvaldo,
Concordo com você em alguns pontos, especialmente sobre alguns módulos que os desenvolvedores tentaram “copiar” outros módulos de outras linguagens, o que acaba complicando o que era para ser simples, especialmente em uma linguagem que tentar simplificar o máximo possível.
Essa tendência é perigosa, pois logicamente a linguagem precisa evoluir, logo, ela também cresce em tamanho e código. Mas, é necessário que os desenvolvedores de hj tenha sempre em mente ao produzir código, tentar ser o mais simples possível. Ainda há desenvolvedores que resolvem o problema, mas não da forma mais eficiente e simples possível. Espero que o time de desenvolvedores de Python tenham essa filosofia ainda marcante no passado.
Abraços,
Marcel
Acredito que Python continua sendo pythonico, mas que a definição de pythonico possa estar mudando com o passar do tempo. É necessário lembrar que Python foi criado ainda nos anos 90, quando boa parte das tecnologias que utilizamos hoje estava engatinhando.
Para acompanhar o crescimento dessas tecnologias e o surgimento de outraas foram necessárias realizar implementações que a princípio não eram pythonicas e acabaram por “subverter” um pouco a linguagem. Mas sempre com o passar do tempo, novas implementações tomam lugar dessas implementações não pythonicas.
Vale lembrar que qualquer pessoa que tiver uma sugestão pode convencer os core developers a votar uma pep e substituir uma parte da biblioteca padrão no Python 2.
Oi Francisco,
É fato que a documentação do Python é boa e está lá pra ser consultada mesmo. Consultar a documentação 1 vez é ok. 2x é aceitável. Mas ter que recorrer à ela *sempre* denuncia que tem algo errado com o que está sendo documentado, concorda?
Lembre-se que para que um desenvolvedor passe para o estágio de ‘foco’ no desenvolvimento é necessário uma quantidade de tempo razoável. Quando você tenta fazer algo com uma biblioteca e não lembra como se faz uma “exceção” é gerada no seu cérebro, você sai do estado de “flow”, comuta de tarefa para ler a documentação e só então volta ao trabalho… Acho isso é contra-producente.
Uma das idéias do ‘pythônico’ é a de deixar as coisas simples de serem usadas para que o nosso cérebro consiga reter todas essas informações enquanto estamos trabalhando. Por isso o título do post. Algumas bibliotecas padrões do Python não seguem esse raciocínio e algumas bibliotecas de terceiro, que são usadas extensivamente, também não.
logging – Como você mesmo já mencionou, foi inspirado no log4j, que não é exatamente um primor do minimalismo. Muita gente já andou reclamando do pacote logging, e inclusive o próprio autor queria dar uma repaginada, mas ficou tudo por isso mesmo.
ConfigParser – faz um multilhão de coisas porque foi feito copiando-se uma implementação de parser quase que industry standard, usada em muitos command lines em C e nos utilitários GNU. Também não é um primor do minimalismo.
email – MIME e SMTP são complicados, governados por dezenas de RFCs arcaicas. Essas coisas também não foram projetadas para ser uma obra de arte minimalista, e o módulo Python, por ser fidedigno as opções, acaba transparecendo isso. É como reclamar que WSGI é complicado, quando só o que você quer é exibir uma página.
xml.dom e xml.sax – ElementTree poderia ser incluida no stdlib, não fosse um porém – ela falha para XML mal formado, ou para schemas mais esotéricos. Estes módulos são um pouco mais resilientes quanto a isso, apesar de infinitamente mais complicados.
re – RegEx é como uma serra elétrica: ela faz bagunça, é barulhenta, mas as vezes não dá pra usar um simples serrote.O módulo simplesmente transparece isso.
from zope import * – Tudo o que é “Zope” é complicado porque basicamente desenvolvem tudo dentro de um mesmo eco-sistema. Muitas coisas que foram desenvolvidas (como o Buildout), apesar de úteis, tem alguma fixação estranha em não seguir o padrão de qualquer outra ferramenta parecida. Então você fica com a impressão de que precisa entender a coisa a fundo, ou não entende. ZODB é uma exceção de algo que foi feito para fazer bem uma coisa só, sem precisar de uma API cheia de camadas.
Enfim… muito da linguagem Python e do stdlib realmente “cabe na cabeça”. A enxaqueca começa quando você começa a usar código que toca algo simplesmente mal-cheiroso (email, regex, gente imitando Java), ou que costuma ser Entreprise Ready (TM) e portanto é maior que o mundo (zope.*).
Artigo interessante, concordo com quase tudo, mas acho que o Python ainda cabe na cabeça, quem não cabe são essa libs unpythonicas.
Já tive vontade de fazer a minha própria lib de log colocar no sourceforge. No mínimo seria algo mais fácil de usar :)
Gostei bastante do artigo. Para lidar com expressões regulares eu uso o reverb.py. Escrevi sobre ele no meu blog: http://victorfontes.com/2010/03/expressoes-regu...
Electricity is really just concentrated lightning.