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 :)

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 :)

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.*).

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.*).

É 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.

É 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.