Eu adoro participar de eventos de tecnologia (você já deve ter percebido isso inclusive), uma das coisas que eu mais gosto é o contato com programadores de outras linguagens e que vivenciam filosofias completamente diferentes das suas.

Apesar de não programar nada em Python, já estive e ainda estou envolvido em alguns projetos em Python, e é engraçado ver como os pythonistas encaram as coisas de forma diferente na hora de resolver seus problemas.

Não lembro ao certo como, mas acabei chegando ao “The Zen of Python” e achei legal compartilhar com vocês. Nada mais é do que uma série de filosofias escritas pelo criador da linguagem Python. Um texto interessante de se conhecer ainda mais para quem não é do mundo Python como eu.

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one— and preferably only one —obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Em português:

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.
Linear é melhor do que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para quebrar as regras.
Ainda que praticidade vença a pureza.
Erros nunca devem passar silenciosamente.
A menos que sejam explicitamente silenciados.
Diante da ambigüidade, recuse a tentação de adivinhar.
Deveria haver um — e preferencialmente só um — modo óbvio para fazer algo.
Embora esse modo possa não ser óbvio a princípio a menos que você seja holandês.
Agora é melhor que nunca.
Embora nunca freqüentemente seja melhor que .
Se a implementação é difícil de explicar, é uma má idéia.
Se a implementação é fácil de explicar, pode ser uma boa idéia.
Namespaces são uma grande idéia — vamos ter mais dessas!

São filosofias extremamente simples e que podem soar óbvias, não é?

Mas porque será que mesmo parecendo tão óbvias, existimos em não aplicá-las?